Hi group

[Guille]

Hello group, I am new to Slate, and I am very amazed about it.
I am writing a GTK wrapper for it, right now, It has some GTK classes
with a few methods wrapped. Just what i needed to write a Workspace.
With the workspace you can evaluate, inspect and print Slate
expressions. Now I am writing an inspector. When I finish with that I
will post the wrapper to the group.

Cheers, Guille

[Guille]

Hi I was wondering how can I upload the wrapper?
BTW: I added a basic Traits Browser

Cheers, Guille

[Timmy Douglas]

You can send it to me in an email and I can add it to the tree
manually (probably preferable for an initial patch like this), or you
could give me a url to your git repository and I can pull from it.

[Guille]

Perfect, I am sending you what I've got. It would be nice if you can
take a look at the dir structure, to see if there is any problem with
it.
Thank you!

[Timmy Douglas]

WOW! It's awesome. I put merged the code into the slate repository. I
put the code in the src/ui instead of the src/ trunk. It worked good
without any changes. I was surprised at how little code there was. One
thing that would be nice is maybe an exit button but there probably
wouldn't be a need to exit eventually if the GUI gets more features
than the repl. I'm posting two screenshots I took for others to see:


http://img123.imageshack.us/ img123/3847/ss20090109ci6.png
http://img175.imageshack.us/ img175/1779/ss20090109bob0.png


(take the space out... i didn't want web crawlers to push the free
hosting over the bandwidth limit if that's even possible)

Where should we take this next?

[Guille]

Thank you,

I think that this steps should be taken:
Add features to the inspector, workspace and traits browser.
Create more apps, ie: the main toolbar, maybe a change sorter?
Add more bindings to the wrapper.

But first, I would like to know:
Right now, I reload the whole thing, each time I test something. Is it
possible to work with the image and then generate the slate files from
the image?
How is source code handled in slate? I only see the treenodes for the
parsed code

[Timmy Douglas]

On Jan 10, 4:03 am, Guille <gui...@losmolina.com.ar> wrote:
> Thank you,
>
> I think that this steps should be taken:
> Add features to the inspector, workspace and traits browser.
> Create more apps, ie: the main toolbar, maybe a change sorter?
> Add more bindings to the wrapper.

ok. what's the difference between a traits browser and an inspector?
They're all objects so you could probably use the same code but
just filter by objects with 'traits' in the printName or something.

> But first, I would like to know:
> Right now, I reload the whole thing, each time I test something. Is it
> possible to work with the image and then generate the slate files from
> the image?

No, this isn't currently possible. When you write a method definition
like:
x@y myfunc [code].

whatever is at y (e.g. Gtk Button traits) gets evaluated to an object.
As you have noticed, using the printName of that object doesn't always
get the correct code back that could evaluate to the same object.

Another issue is that prim_method_on or prim_accessor_on
(primitives.c)
and method_define(method.c) don't store the roles passed from the
primitive in the
method definition. They just put the roles into the objects directly.
That is an easy fix that I could change so that you could get those
from a method
definition, but in order for you to be able to put those in a file
later on, you'd have
to store all the defined methods somewhere. That also doesn't consider
how you'd
store the objects you create. So I'm not sure if this would be a good
idea.

I think some people have mentioned in the past that they'd rather have
a text
file editor where you could just evaluate specific things rather than
have what
squeak does which is to store everything in one file or one image.

If we had an editor you could edit the file you're working on while
you're using slate,
and then you wouldn't have to reload every time you make a change.
Another thing to
consider is that if we write a whole gui IDE in gtk, will we be able
to share code
if there is a separate windows IDE or mac os x IDE? So there are some
advantages
to having the IDE in slate itself. I would support both and I think
it's always useful to have
a good set of gtk bindings.

> How is source code handled in slate? I only see the treenodes for the
> parsed code

I think only the parsed code is stored. That's probably why slate
development has been
file based all these years.

[Guille]

> ok. what's the difference between a traits browser and an inspector?

Really none, I thought that too, I'll merge them

> They're all objects so you could probably use the same code but
> just filter by objects with 'traits' in the printName or something.
>

> If we had an editor you could edit the file you're working on while
> you're using slate,
> and then you wouldn't have to reload every time you make a change.

So when you accept the method you save the source into the file and
compile the code into the image?
When the user browse the source code,
-first it should try to read the source file to get the source.
-second, try using the SourceWriter
-and last, do a printString

Ok, I will try to do that

> Another thing to
> consider is that if we write a whole gui IDE in gtk, will we be able
> to share code
> if there is a separate windows IDE or mac os x IDE? So there are some
> advantages
> to having the IDE in slate itself. I would support both and I think
> it's always useful to have
> a good set of gtk bindings.
>

Yes, may be we can write the tools using MVC, and you could have
different "V" implementations, morphic, gtk, win, whatever.

[Timmy Douglas]

On Jan 10, 12:57 pm, Guille <gui...@losmolina.com.ar> wrote:
> So when you accept the method you save the source into the file and
> compile the code into the image?
> When the user browse the source code,
> -first it should try to read the source file to get the source.
> -second, try using the SourceWriter
> -and last, do a printString
>
> Ok, I will try to do that

I'm not totally sure if I understand what you're saying...
particularly
the SourceWriter/printString part.

In other words, I think all we really need to edit slate code is a
text editor like gnome text editor with tabs for separate files and a
way to inject specific portions of code to be evaluated and compiled
into the image.

Later we could add a way for the text editor to read/parse the code
while you're editing it so you could click on selectors and jump to
implementations of them (which would require some support from the
running image... perhaps we can decide what additional metadata to
store in function definitions? I'm not sure if we get too much
information from the parser though)

[Guille]

>
> I'm not totally sure if I understand what you're saying...
> particularly
> the SourceWriter/printString part.
>

Let me explain it a little bit.
When the user selects a method, the editor tries to find it reading
the source file.
It may be possible that the source is not found, or may be it is
inconsistent. If it is not found, the source may be recreated using
the SourceWrite (right now, it is implemented like that, see src/ui/
gtk/traitsbrowser.slate, tb@(Gtk TraitsBrowser traits) loadCode.
Then if that is not possible we could disassemble the code

> In other words, I think all we really need to edit slate code is a
> text editor like gnome text editor with tabs for separate files and a
> way to inject specific portions of code to be evaluated and compiled
> into the image.
>

I agree

> Later we could add a way for the text editor to read/parse the code
> while you're editing it so you could click on selectors and jump to
> implementations of them (which would require some support from the
> running image...  perhaps we can decide what additional metadata to
> store in function definitions? I'm not sure if we get too much
> information from the parser though)

Yes, that is what I am thinking too.