BLOX vs GTK

Hi,

Luca's mail reminded me one thing I'm thinking about.

Premise:
We need a good development environment for GST -
workspace, convenient browser with refactoring
and source code management support, easy-to-use
inspector and debugger and lot of other support
tools. All in GUI.

Paolo, are there any documents about Blox?
About it's concept, implementation. Any
tutorial about creating gui applications in Blox?
I tried to read BloxBrowser, but it looks looks
very strange (in comparison to VisualWorks/SmalltalkX/Squeak
frameworks), I was unable to realize what method I
had to change to add a new menu item to workspace menus
and so on. It looks, that some widgets are not supported
in Blox, but are supported in GST GTK+ binding.


What about to forgot Blox and build GST tools on
pure GTK?

Advantages:
 - GTK+ 2.0 is quite good toolkit, is object-oriented,
   and is de-facto standard in OpenSource UNIX environment
   (can you imagine modern unix workstation without GTK+2.0
   libraries?)
 - GTK+ 2.0 concept (objects, signals, event) is relatively
   well-described in hundreds of tutorials, manuals and so on
   and is well-known in programmers community - so almost
   everybody could write small GUI tool using GTK without
   learning yet another toolkit (good for not-yet-smalltalkers)
 - We will have many usefull/specific widgets, not only those
   available in all supported toolkits.
 - It save gst developer's time, cos there will be no need to
   create Blox adaptor every time the new widget will appear.
 - GTK+ have one of the best systems of creating ang binding
   shortcuts (one of the most problematic topic in VW,Morphic
   and St/X toolkits :-)
 - We can write relatively thin software layer (extension)
   on the top of GTK to provide same API (resp. API with
   same concept and ideas) as is available in VW and/or
   Smalltalk/X (which is really very easy to use and many
   smalltalkers are familiar with it and really love it).

Disadvantages
 - GST will be limited to platforms where GTK+2.0 is available.
   But now, gst runs just on unixes and GTK+2.0 runs well both on
   Unix/X-Window and Windows (two main platforms)

What do you thing about?


Jan

P.S.: Of course, it will be neccessary to stabilize GTK plugin
      first.
      I would like help,but I don't know how :-(







_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Paolo, are there any documents about Blox?
> About it's concept, implementation. Any
> tutorial about creating gui applications in Blox?
>  
Blox is quite easy to understand (look at the demos in browser/test.st
for an example).  The documentation taken from the source code is a
decent reference.

The browser is another story.  The model-dispatcher system is incredibly
complicated and I never really unravelled it.  Even the Namespace
browser was mostly done by cut'n'paste'n'hope-it-works, I'm not very
pleased to say...
> It looks, that some widgets are not supported
> in Blox, but are supported in GST GTK+ binding.
>  
Though consider that the GTK+ bindings are inferior because they don't
support Smalltalk models: for example, everything has to be a string to
put it into a CList (or whatever it's called these days).
>  - It save gst developer's time, cos there will be no need to
>    create Blox adaptor every time the new widget will appear.
>  
It will have less flexibility for the toolkit user though.  It can be
really useful to have wrappers that convert a Smalltalk model to a GTK+
model, or something like that.
>  - We can write relatively thin software layer (extension)
>    on the top of GTK to provide same API (resp. API with
>    same concept and ideas) as is available in VW and/or
>    Smalltalk/X (which is really very easy to use and many
>    smalltalkers are familiar with it and really love it).
I disagree, but... :-)

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote:
>
> The browser is another story.  The model-dispatcher system is incredibly
> complicated and I never really unravelled it.  Even the Namespace
> browser was mostly done by cut'n'paste'n'hope-it-works, I'm not very
> pleased to say...

I think the model-dispatcher system is quite elegant, but I couldn't
apply it easily to widgets like the GtkTextBuffer/View, where a lot of
the state is held outside of the image (unless you want to do a lot of
duplication).

> It will have less flexibility for the toolkit user though.  It can be
> really useful to have wrappers that convert a Smalltalk model to a GTK+
> model, or something like that.

In fact you *have* to have some kind of proxy system if you want to be
able to restart the image. That doesn't *have* to be a set of wrappers
(for example, it could be a text representation of the interface like
glade or XUL), but having wrappers is the most obvious way.

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Mike Anderson wrote:
> Paolo Bonzini wrote:
>  
>> The browser is another story.  The model-dispatcher system is incredibly
>> complicated and I never really unravelled it.  Even the Namespace
>> browser was mostly done by cut'n'paste'n'hope-it-works, I'm not very
>> pleased to say...
>>    
>
> I think the model-dispatcher system is quite elegant,
You mean you understood how PList and friend are updated? :-P
>  but I couldn't
> apply it easily to widgets like the GtkTextBuffer/View, where a lot of
> the state is held outside of the image (unless you want to do a lot of
> duplication).
>  
Yes, and the same is true also for relatively simpler widgets like a
single-column TreeView.

Paolo



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

In data 05 ottobre 2006 alle ore 17:52:20, Jan Vrany  
<[hidden email]> ha scritto:

Think about having the same code with a Qt backend... i think of BLOX like  
a wrapper, like wxWidgets at all.
However, having BLOX on top of a toolkit means a lot of maintenance and a  
reduction of performance.
Surely, BLOX Browser is not something so much good as development  
environment, but this can be improved at any time.

The most important thing is to mantain the stability and backward  
compatibility between GUI toolkits.

Bye.

--
http://lethalman.blogspot.com - Thoughts about computer technologies


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Paolo Bonzini wrote: Well I thought I did... more-or-less... but you're making me doubt
myself :-s

>>  but I couldn't
>> apply it easily to widgets like the GtkTextBuffer/View, where a lot of
>> the state is held outside of the image (unless you want to do a lot of
>> duplication).
>
> Yes, and the same is true also for relatively simpler widgets like a
> single-column TreeView.

Yes :-)

What I forgot to say earlier is that, while I think the bindings are
very usable for small Gtk apps, if I was going to write a large Gtk
application, I would have another go at improving the header parser.
Currently there are quite a lot of things missing which are actually
quite crucial, even though they don't appear so at first. I'm thinking
of things like support for drag and drop.

What it needs most of all is a test suite so that it is possible to see
what has been parsed and what hasn't (because it uses some arcane C). It
occurred to me that searching for the comments used to auto-generate the
Gtk docs might be a good way to get that.

BTW The attached files are a working example of drag and drop if anyone
has a use for that.

Mike

CStruct subclass: #GtkTargetEntry
        declaration: #(              
                        #(#target #string)    
            #(#flags #uInt)
            #(#info #uInt)
        )
        classVariableNames: ''
        poolDictionaries: ''
        category: ''
!

CStruct subclass: #GtkTargetPair
        declaration: #(              
                        #(#target #int)    
            #(#flags #uInt)
            #(#info #uInt)
        )
        classVariableNames: ''
        poolDictionaries: ''
        category: ''
!

CStruct subclass: #GtkTargetList
        declaration: #(              
                        #(#list #(#ptr #int))    
            #(#refCount #uInt)
        )
        classVariableNames: ''
        poolDictionaries: ''
        category: ''
!

CStruct subclass: #GtkSelectionData
        declaration: #(
                        #(#selection #uLong)
                        #(#target #uLong)
                        #(#type #uLong)
                        #(#format #int)
                        #(#data #(#ptr #uChar))
                        #(#length #int)
                        #(#display (#ptr #uLong))
                )
        classVariableNames: ''
        poolDictionaries: ''
        category: ''
!

GList methodsFor: 'C call-outs'!

length
    <cCall: 'g_list_length' returning: #uInt args: #( #self )>
!

nthData: n
    <cCall: 'g_list_nth_data' returning: #cObject args: #( #self #uInt )>
!
!

"CStruct subclass: #GTypeInstance
        declaration: #(
                #(#gType #int)
                )
        classVariableNames: ''
        poolDictionaries: ''
        category: ''
!

GTypeInstance subclass: #GObject
        declaration: #(
                #(#refCount #uInt)
                #(#qdata #(#ptr #int))
                )
        classVariableNames: ''
        poolDictionaries: ''
        category: ''
!

Transcript << 'Recompiled GObject'; nl.
!

GObject subclass: #GdkDragContext
        declaration: #(
          #(#protocol #int)
          #(#isSource #int)
          #(#sourceWindow #(#ptr #int))
          #(#destWindow #(#ptr #int))
          #(#targets #(#ptr #int)) -- GList
          #(#actions #int)
          #(#suggestedAction #int)
          #(#action #int)
          #(#startTime #int)  
                )
        classVariableNames: ''
        poolDictionaries: ''
        category: ''
!"


| reqs |
reqs := #( 'MUtility' 'GTK' ).
(Smalltalk hasFeatures: reqs) ifFalse:
    [ PackageLoader fileInPackages: reqs.
    ObjectMemory snapshot: 'ncdroptarget.im'.
    Transcript << 'Snapshotted with packages loaded to ncdroptarget.im' ].
!

Namespace current: GTK
!

#('GtkChanges.st' 'GtkConvenience.st') do:
        [ :each | FileStream fileIn: each ].
!

Namespace current: Smalltalk
!

Object subclass: #NcDropTarget instVarNames: 'wnd img'
!

NcDropTarget methodsFor: 'everything'!

dropEvent: widget context: context x: x y: y time: t
        | a a1 a2 |
        Transcript << 'dropEvent'; nl.
        widget = img ifFalse: [ Transcript << 'Wrong widget!'; nl. ].
        a := GTK.Gdk atomIntern: 'text/uri-list'  onlyIfExists: false.
        (GTK.Gdk atomName: a) printNl.
        "a := context suggestedAction value."
        GTK.Gtk dragGetData: widget context: context target: a time: t.
        ^true
!

dragDataReceived: widget context: context x: x y: y data: data info: info "int" time: t
        | n d |
        Transcript << 'dragDataReceived'; nl.
       
        "Process drop"
        data changeClassTo: GTK.GtkSelectionData.
        n := data length value.
        Transcript << 'Length: ' << n ; nl.
        n > 0 ifTrue:
                [ d := data data value.
                0 to: n - 1 do:
                        [ :i | Transcript << (d at: i) << ' ' .].
                Transcript nl. ].
       
        GTK.Gtk dragFinish: context success: true del: false time: t
!

dragMotion: widget context: context x: x y: y time: t userData: aString
        GTK.Gdk dragStatus:  context action: GTK.Gdk gdkActionCopy time: t.
        ^true
!
       
buildWindow
        | tgt n |
        wnd := GTK.GtkWindow new: GTK.Gtk gtkWindowToplevel.
        img := GTK.GtkImage newFromFile: 'target.png'.
        wnd add: img.

        GTK.Gtk
                dragDestSet: img
                flags: 0 "(GTK.Gtk gtkDestDefaultHighlight)"
                targets: nil
                nTargets: 0
                actions: 1 "default".
        GTK.Gtk dragDestAddTextTargets: img.
        GTK.Gtk dragDestAddUriTargets: img.
       
        tgt := GTK.Gtk dragDestGetTargetList: img.
        tgt := tgt list value changeClassTo: GTK.GList.
        n := tgt length.
        Transcript << 'Target list: ' << n; nl.
        0 to: n - 1 do:
                [ :i | | p |
                p := (tgt nthData: i) changeClassTo: GTK.GtkTargetPair.
                (GTK.Gdk atomName: p target value) printNl. ].
        Transcript << 'end of list.'; nl.
                                               
        tgt :=
                [ :name | | e |
                e := GTK.GtkTargetEntry new.
                e target value: name.
                e flags value: 0.
                e info value: 57.
                img  ].
        tgt value: 'PRIMARY'; value: 'SECONDARY'.
               
               
        img
                when: 'drag-drop'
                        send: #dropEvent:context:x:y:time:
                                to: self;
                when: 'drag-data-received'
                        send: #dragDataReceived:context:x:y:data:info:time:
                                to: self;
                when: 'drag_data_received'
                        send: #dragDataReceived:context:x:y:data:info:time:
                                to: self;
                when: 'drag-motion'
                        send: #dragMotion:context:x:y:time:userData:
                                to: self
                                        with: 'img'.
!

run
        wnd isNil ifTrue: [ self buildWindow ].
        wnd showAll.
        GTK.Gtk main
!
!

GTK.Gtk gstGtkInit
!

NcDropTarget new run
!


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Mike Anderson wrote:
[...]
> What I forgot to say earlier is that, while I think the bindings are
> very usable for small Gtk apps, if I was going to write a large Gtk
> application, I would have another go at improving the header parser.
> Currently there are quite a lot of things missing which are actually
> quite crucial, even though they don't appear so at first. I'm thinking
> of things like support for drag and drop.

You could always port SWIG; it already does this, autogenerating bindings for
Perl, PHP, Tcl, Ruby, Python, Java, Guile, Mzscheme, Chicken, Ocaml, Pike, and
C# (he says, cut and pasting from the Debian package description). It
shouldn't be hard to make it generate Smalltalk as well.

However, I'd strongly suggest going for something like wxWidgets instead of
GTK. That way you gain platform portability. GTK is nice and all, but you
really don't want to use it on Windows or OSX --- it runs, but looks dreadful.
wxWidgets will give you a consistent API with native look and feel on all
(supported) platforms.

--
+- David Given --McQ-+ "Gaping from its single obling socket was
|  [hidden email]    | scintillating, many fauceted scarlet emerald..."
| ([hidden email]) | --- Jim Theis, _The Eye of Argon_ (spelling
+- www.cowlark.com --+ original)



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> You could always port SWIG
Yes, that's a good possibility.
> However, I'd strongly suggest going for something like wxWidgets instead of
> GTK. That way you gain platform portability. GTK is nice and all, but you
> really don't want to use it on Windows or OSX --- it runs, but looks dreadful.
>  
It does not look *that* bad on Windows; and on OS X, the native
VisualWorks GUI is so slow, clunky and in the end non-standard, that in
the end I always use the X11 one -- which looks pretty much like GTK.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On Pá, 2006-10-06 at 07:47 +0200, Paolo Bonzini wrote:
> > You could always port SWIG
> Yes, that's a good possibility.

Hmm, great idea. I will look on it. SWIG could solve lot
of my problems (even in Smalltalk/X :-)

Jan


>
> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> http://lists.gnu.org/mailman/listinfo/help-smalltalk



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

David Given wrote:
Yes, a while back I posted about Sport when I meant SWIG (hey, it's hard
 to keep track sometimes).

> However, I'd strongly suggest going for something like wxWidgets instead of
> GTK. That way you gain platform portability. GTK is nice and all, but you
> really don't want to use it on Windows or OSX --- it runs, but looks dreadful.
> wxWidgets will give you a consistent API with native look and feel on all
> (supported) platforms.

I'd agree totally, but wxWidgets is C++, isn't it? That means we'd need
a C wrapper unless such a thing already exists.

[Personally, I run GIMP on Windows, and it looks fine to me. I don't
understand how you (and other people) can describe it as dreadful]

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

Mike Anderson wrote:
[...]
> I'd agree totally, but wxWidgets is C++, isn't it? That means we'd need
> a C wrapper unless such a thing already exists.

I suspect SWIG will do that for you as part of the binding generation.

> [Personally, I run GIMP on Windows, and it looks fine to me. I don't
> understand how you (and other people) can describe it as dreadful]

Well, it doesn't use the native widget set, which means it is, by definition,
wrong. GTK on Windows normally uses a skin that tries to make it look more
like real Windows widgets, but there's a limit as to how far you can go with
that approach --- the result is always going to look *nearly*, but not quite,
like the native widget set. (You're typically in a world of pain if the user
changes any desktop settings.) What's more, it doesn't let you change the user
interface to match application standards. Your application is not only going
to look funny, but it's going to behave funny, too.

Cross-platform widget sets like wxWidgets, which use native widgets for all
their rendering, solve all these problems in a single stroke; and what's more,
they can use native functionality whereever possible, so you don't have to
worry about weird file dialogues, button ordering, toolbar graphics, keyboard
shortcuts, etc.

--
+- David Given --McQ-+ "There is one thing a man must do // Before his
|  [hidden email]    | life is done; // Write two lines in APL // And make
| ([hidden email]) | the buggers run."
+- www.cowlark.com --+ --- The Devil's DP Dictionary


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

David Given wrote:
Real Windows widgets. What, like in Media Player and Office, you mean?

I'm not saying you don't have a point, but you are exaggerating.
"Dreadful" means it looks really bad, which is not the same as looking
non-standard. "World of pain" may describe your experience trying to
force the non-standard back into the standard, but it doesn't describe
the user's experience using the non-standard experience. "Funny" I'll
accept (but I think you mean it perjoratively).

Standardization is the enemy of distinctiveness and competetive
advantage. You need both.

Right, I'm way off-topic now.

Mike


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

On 10/6/06, Mike Anderson <[hidden email]> wrote:
I don't agree totally. In my opinion, GTK is not really any
portability problem at the moment and wxWidgets is only portable
because of allot of preprocessor statements and functions that turn
out to be preprocessor macros (and it's C++). So, my opinion, GTK
doesn't look bad on windows, and wxWidgets doesn't introduce more
portability (only a more native look). Also note that there is no gst
running on w32 at the moment and this is *not* due to GTK.

Bram


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

In data 08 ottobre 2006 alle ore 18:00:04, Bram Neijt <[hidden email]>  
ha scritto:

I totally agree with you

--
http://lethalman.blogspot.com - Thoughts about computer technologies


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk