Slate UI

[Brian Rice]

I'm including the main mailing list. For future reference, I would 
strongly prefer that Slate questions be directed to the mailing list or 
at least cc'd there (emails have multiple recipient fields for a 
reason), any questions directed to me over email about general Slate 
issues will be replied to there.

On Jul 19, 2004, at 9:04 AM, Waldemar Kornewald wrote:

> Hi Brian,
> from the #slate discussions I got the impression that you (or only 
> Lee?) want to drop files in Slate(/OS). Are there docs about what you 
> plan to do? Will data be represented by objects living in the image 
> (and the image is like a partition, especially in SlateOS)?

No. Yes. I am not sure yet. Just "file" and "image" are not a good 
enough vocabulary; there need to be whatever range of abstractions are 
appropriate. See Squeak. (Actually, if the people who kept asking me 
questions actually looked at Squeak and its satellite tools every once 
in a while, they'd be able to help instead of asking for clues.)

> What ideas do you have for the CVS replacement and does it fit to the 
> no-files idea?

I don't. As always, I mine other systems for ideas and pick a 
set/combination that fit. Darcs (Haskell) and Monticello (Squeak) and a 
few others interest me, but they are not really "live"-oriented.

> Is it possible to make Slate compile code that is at least as 
> good/fast as C++ code? It does not matter if it takes four times 
> longer (but not more than that) to compile with "extreme 
> optimization", but I would like to drop C++ and only use Slate for 
> everything. With extreme optimization I could optimize very important 
> modules (scientific calculations, for example) and leave the rest at 
> normal optimization.

That's a question for Lee. There's no way in the world that I can tell 
you what's possible there, as I am not really a systems programmer.

>>> congratulations to your progress with Slate! So, you should soon 
>>> start
>>> with the UI, right? I would like to make one little suggestion (you
>>> probably know this already):
>>> Please make the UI multi-threaded like the BeOS' one. Although BeOS
>>> was not really fast (under the hood) it made the impression that it
>>> was. This is because the UI was extremely responsive. My wish is that
>>> you do not forget about this. I think the other UIs are slower 
>>> because
>>> they are single-threaded and not optimized for responsiveness.
>>
>> I know this already. I will definitely be trying to do this.
>
> Cool, maybe I can help you a little bit with my BeOS experience 
> (threading-wise).

>> Unfortunately, I am in favor of extreme flexibility, but the point of
>> Slate is to do things flexibly with a minimum of code, so that this
>> should not be a real problem. On the other hand, I don't like too much
>> fancy stuff, and am fiendishly interested in reducing the number of
>> implementation-concepts to a minimum, hence the focus on the
>> presentation type layer and other such things.
>
> Okay. My actual focus was on the UI that is presented to the 
> developer, not the code (although it is very important to make 
> programming easier, too). In Squeak it is rather complicated to come 
> along. It is very unintuitive to find the browser and then finding the 
> Base64 code...in popular languages (Java, C#, C++) you can start right 
> after you know how to click on "Compile". There must be a very simple 
> and quick way to actually start programming.

Agreed, and it should scale well.

>>> Will you definitely use Cairo for the UI? So, for my SlateBeOS port I
>>> would have to port Cairo. Are there other libraries I would have to
>>> port? GTK? QT? If it is too much, I will not be able to port it on my
>>> own...do you know the email-addresses of some other BeOS devs who 
>>> want
>>> to port Slate?
>>
>> Well, here's the deal. Every API to the UI libraries is a "backend" 
>> and
>> encapsulated, so whatever backends people decide to write are what 
>> will
>> be supported. In principle, backends are interchangeable on a basic 
>> API
>> level and our framework just happens to be Cairo-like so that that's
>> pretty easy there. If a backend isn't available for your platform, 
>> just
>> pick an API that is ported and try that; raw X11 was already done 
>> under
>> Lisp by Doug Brebner, and should be really easy to re-do.
>
> Good, then, I think porting Cairo is the best solution (the BeAPI is 
> vector-like, so that should not be too complicated), but I will wait 
> until everything is in-place (maybe someone else is faster ;).

If everyone kept waiting, nothing would happen.

>> However, until Slate has proper concurrency support and that is tied 
>> in
>> to the I/O framework, a multithreaded UI and Slate will not interact
>> very beneficially.
>
> At #slate you mentioned that Slate will not allow for easy parallel 
> computation. Why? :)

Well, it's pretty obvious, or should be - any language based on 
procedures / side-effects is going to require some kind of restrictions 
in order to be simple to reason about in parallel. The languages that 
excel at parallel / concurrent work are those where side-effects are 
really local by default.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/