On Sat, Jul 25, 2009 at 4:47 AM, Felix Holmgren<[email protected]> wrote:
> I've been checking out Etoile for a while, and today I took some more
> time to read a lot of the docs. I thought I'd share some of my initial
> reactions and some random thoughts and questions.
thanks, and welcome :)
> I think the Etoile web page definitely communicates that this is
> something else than your average GNUstep project. The combination of
> some pretty graphics with those fragments of Objective-C code caught
> my eye. That said, I've later come to feel that the front page (and
> most of the site) is too heavy on prettiness and too light on actual
> information. Although I sensed that something interesting was going on
> here, I was not sure whether et was more than an attempt to give gs a
> decent look and feel, combined with a couple of people working on some
> pet projects without any real cohesion.
>
> It wasn't until I read the faq (today) that I really started to get a
> more concrete picture of what et is trying to accomplish. In my
> opinion the info in the faq could be expanded into several pages and
> could easily be made into a "tour of Etoile". It is definitely the
> single most informative document I've seen so far (and it's not really
> so much of a faq as it is a description of the system. At this point,
> these features stand out for me as defining et.
>
> * A hot runtime
> * Non-file based object metaphor
> * Zooming interface
> * Dynamic language support
> * Updated gs theming
An "Etoile tour" is a very good idea, yes.
> Secondly, I read (half-skimmed) David's papers on the runtime and got
> doubly inspired. Prior to reading those I wasn't really sure what the
> Language Kit was all about. Just a hook for various "scripting"
> languages? But now, between the faq and the papers, I'm really
> starting to get a feeling of et as coherent system. Again, I think
> some of the info in the papers should/could be made much more visible
> on the web page.
>
> A question: how much of the runtime described in the papers is
> actually implemented at this time in et?
> I also wonder how much of these ideas are fed into gs and how much is
> et specific.
>
> It seems to me that the web page should be 90% geared towards
> developers for the time being. Even if someone else came across the
> page and liked it, they wouldn't really be able to get very far in
> trying to use et, so it seems a waste of resources to go out of your
> way to attract them. Not in the long term, of course, but for now.
> Attracting active developers is, I suppose, much more important. I
> myself would have been (even) more easily hooked if the front page had
> a list of features ("flexible, dynamic runtime with support for...",
> "updated ui metaphor...", "zooming interface...", "documents not
> files..."), with a link for a fuller explanation of each item. Maybe
> I'm stating the obvious, and probably your answer is "yes it's on our
> todo list", but I think you already have a lot of information and
> examples available, and you just have to put them up front.
yes.
> About the proposed themes: these obviously constitute a pretty big
> step in the world of GNUstep themes, but -- I'm sorry -- for the
> average non-geek, they are not really close to a cutting-edge, 21st
> century feeling. Well, maybe close but... I should add that I don't
> think any open source desktop really is. I know many developers simply
> scoff at such obsession with cosmetic detail but users don't. And
> personally I'm as much a user as a developer and I care a lot about
> how my work environment feels. I'm sure you would agree that this has
> nothing to do with bloated, candy filled interfaces, but with the
> small details that make users feel that the gui inspires them, as
> opposed to merely letting them get something done. And again on a
> completely personal note, all that purple doesn't really do it for me.
> I think etoile is definitely on the right track, but it would be worth
> to keep on polishing the proposed themes and getting some external
> feedback on them.
I think we all are very interested in good GUI design and a good UI
theme. Quite a lot of effort/discussion went in the Nesedah theme for
example, but as all design, it's a result of a set of constraints..
that being said I'm not saying what we have is the end of all things
and we shouldn't work on that more -- to the contrary :)
(though maybe that's not the most pressing thing to work on at the moment)
> Btw: it seemed like you're saying (I read through a couple of
> interviews too) that Apple's horizontal menu bar was a downgrade from
> OpenStep's vertical one, and yet it seems like you're going for a
> horizontal bar yourselves. Am I wrong?
Personally, I like both, maybe with a bit of preference for the
OpenStep's ones. But at the end, we decided to use the horizontal menu
bar for a few reasons:
- easier to reach (fitt's law)
- works better for accomodating a status area
- less foreign to people
What I like in the NeXTSTEP vertical menu is that they are accessible
anywhere with a right-click, that it's easy to drag submenus off and
thus rearrange your workspace/workflow easily (as in addition, those
teared-off menus remember their positions between application
restart).
We do provide those functionalities with Etoile's menus, so I think
that's a pretty good compromise all in all (well the tear-off
capability is not well functioning currently, but you get the idea
;-).
> Language Kit: from some of the examples and discussions, I first got
> the feeling that it was just about putting some Smalltalk syntax and
> block semantics on top of the gs runtime and libraries. There seemed
> to be a focus on compile time tricks, that to me looked kind of
> contrary to the spirit of Smalltalk. As I said, after reading the two
> papers I got a completely different appreciation of the et runtime,
> but I'm still pretty unclear about how Language Kit will work for
> languages whose libraries are not easily mapped onto gs classes. What
> will the benefits be in that case? Why not just create a llvm front
> end?
For me the main interest of LK is the Smalltalk implementation,
because as david would say, I'm a Smalltalk fanboy :)
What this give us is a simpler/cleaner language to write applications
with, but more importantly, a lot more dynamicity (one of our goal is
to be able to develop an application fully at runtime, for example),
yet without breaking the link to existing code (objective-c, c, c++),
allowing for great reuse. So basically we can develop apps in an even
better environment than what Objective-C can provide, yet not losing
much in the process.
Having other languages in LK will be added bonus, as long as they can
be mapped nicely to the runtime -- this does tend to limit us to
dynamic languages, yes. But having a JavaScript-looking language for
example will certainly be of some use.
The main benefit of LK is that by using the same runtime as
objective-c, you have a toll-free integration with existing
Objective-C frameworks.
> Also, I was wondering if it would be of interest to implement fancier
> parsing as part of Language Kit. Maybe parser combinators? Or parsing
> expression grammars? Would that seem like something that belongs in
> Etoile?
Yes, probably more belonging in LanguageKit, but yes I think that'd be cool.
> Well I have and will have a lot more questions. I'm really looking
> forward to seeing how Etoile develops.
--
Nicolas Roard
"I love deadlines. I like the whooshing sound
they make as they fly by." -- Douglas Adams
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
