[Gambas-devel] Gambas on Cygwin
Brandon Bergren
bdragon at ...185...
Tue Jan 18 18:06:24 CET 2005
--A note about the rest of this mail--
Ok, with this mail, please ASSUME gb.form is the root of all gui stuff for
my entire email here. I'm still kinda confused about the current layout of
components. Keep in mind I haven't ever actually USED a fully working copy
of
gambas (like with the form designer and all), so if I'm saying something
really stupid here, please tell me nicely what all this stuff is really
called, from the user's perspective. All my concerns are about
being able to make native ports to other systems, in an abstract way, like
JAVA's AWT. It's like being farsighted.
On Tue, 18 Jan 2005, Benoit Minisini wrote:
> 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!
I think gb.form should be more abstract. than "X11."
There's more windowing systems than X.
gb.form should only have stuff like "Button" or "Image" or "Filebrowser",
and let the implementors worry about the specifics.
Maybe gb.form.X11 would be a good place for what you say.
>> | 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
>>
----my main point-----
The thing I wanted to make sure of was that gb.form should be able to be
driven by all gb.*.form components. So if somebody codes for gb.form, they
don't need to worry about what the users use as the toolkit or platform.
I don't think it would be a good idea for gb.form to do anything more than
the "big idea" stuff of there being Buttons, Labels, Checkboxes, Some
Sort of An Event Queue, etc, etc.
----------------------
---rambling section---
Maybe there should be a seperate section for lower level
implementations...
---What components are shown to the user, important ones flagged--
*gb.form: abstract stuff like button, window, container objects.
*gb.form.ogl: Portable OpenGL
*gb.form.ogl.util: GLUT type stuff, reimplemented by whatever toolkit is
providing the opengl window.
gb.form.ogl.glx: X specific OGL
gb.form.ogl.win: win32 specific OGL
gb.form.ogl.aqua: aqua specific OGL
gb.form.system.X11: direct access to handles, etc.
gb.form.system.GDI: direct access to windows GDI handles, etc.
gb.form.system.aqua: direct access to osx window handles, etc.
gb.form.system: Some sort of abstract way of doing window handles?
gb.form.toolkit.*: access to low-level toolkit features, etc. (up to the
toolkit component implementor to decide)
-------------------------
---The low level stuff. Shouldn't be directly used by the user. More
of a source code layout thingie.----
gb.system.graphics.X11 IMPLEMENTS gb.form.system.X11, gb.form.system
gb.system.graphics.GDI IMPLEMENTS gb.form.system.GDI, gb.form.system
gb.system.graphics.aqua IMPLEMENTS gb.form.system.aqua,
gb.form.system, gb.form.toolkit.aqua
(special case)
gb.system.graphics.aqua.form IMPLEMENTS gb.form
gb.system.graphics.fox.form IMPLEMENTS gb.form
gb.system.graphics.fox IMPLEMENTS gb.form.toolkit.fox
gb.system.graphics.aqua.form IMPLEMENTS gb.form
gb.system.graphics.qt.form IMPLEMENTS gb.form
gb.system.graphics.qt IMPLEMENTS gb.form.toolkit.qt
gb.system.graphics.gtk.form IMPLEMENTS gb.form
gb.system.graphics.gtk IMPLEMENTS gb.form.toolkit.gtk
gb.system.graphics.fltk.form IMPLEMENTS gb.form
gb.system.graphics.fltk IMPLEMENTS gb.form.toolkit.fltk
(I hope you get the idea)
And unless the developer wants to tie their program to a specific
platform/toolkit, or needs advanced features, they use:
gb.form
gb.form.ogl
gb.form.ogl.util
and if they want to target, say, QT,
gb.form.toolkit.qt
I hope somebody can understand exactly what my concern is here.
Feel free to rephrase/rebuke/extend/whatever.
----end rambling section---
>> 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.
I was referring to subclassing. Stick the low level junk like handles in
gb.form.x11
and
let the derived classes use it so they don't have to reimplement 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.
Oh. I was assuming that gb.form was the root of all the GUI stuff.
There should be some sort of target that lets you use all the abstract gui
stuff without worrying about how it was implented. I assumed gb.form was
that target.
>>
>> 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.
>>
Really, my concern is purely architectural. I don't know anything about
what the split would entail. My concern is that there should be a well
defined target for someone writing a drop-in replacement for the GUI
plugin.
>> | 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.
I just think that there should be a well defined abstraction for the whole
gui.
>>
>> 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
>>
>
No. Mine is the boring and too long one. Yours is quite concise. ;P
Thanks.
> 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...
>
Yes, my point was the user shouldn't have to worry about what toolkit they
are using, unless they need to do low level stuff, like interact with
windows outside the application's widget tree.
I really think just gb.form should be enough for most users.
If someone writes their program to use gb.form, they shouldn't have to
worry about whether they are on X11, Windows, Mac, Palm, whatever.
Um, I think I rambled enough.. Sorry about the length.
If you read this far, go ahead and send a reply. ;)
--Brandon
More information about the Devel
mailing list