[Trisquel-devel] GNUkCaH || gnuHaCk
Aitor Ruano Miralles
aitux.boot at gmail.com
Mon Aug 17 12:39:19 UTC 2009
El dl 17 de 08 de 2009 a les 00:54 -0700, en/na william Herrera va
escriure:
I have nothing to say, OpenStep rulezzz o.O
> Hi,
>
> Ricardo welcome back... I hope you've enjoined the journey.
>
> Ricardo Mottola wrote:
>
> >My intention is that by installing the basic gnustep applications and
> then picking what >needed from GAP a user can tailor his environment
> for his needs. This is what I want to >keep as much as possible in
> GAP: if somebody wants X and not Y, he only gets X. Of >course, not to
> the limit where making Kits or libraries is not really useful, but I
> want to >avoid the "one big blob" concept that some projects have.
>
> Your idea is great, I think GAP is solid gold for GNUstep users and
> developers since it provides a native repository for the platform, but
> this is also the main difference with the GNUkCaH || gnuHaCk project.
> We DO want to deploy a "one single piece of software and concept". In
> order to avoid the "one big blob" issue, the desktop will be
> descentralized through modular mini/major components, instead of just
> picking up external apps whose authors keep different goals and
> features in mind, flooding the environment wiht non-used options in
> every release.
> With mini-apps we'll reach high performace, elegance and simplicity
> accomplishing the desired task, like the "old school UNIX application
> style".
> With major-apps we'll reflect the real computing through
> terminal/GUI/web/etc.. instances.
> So with the embedded i-functionality, the applications will be
> natively developed and supported by the desktop, and the GAP
> collection (or other applications source) will let the user to add
> more "salsa" to the environmet if needed.
>
> By the way, the "desktop" term is used (by me) to identify the
> environment concept, not to follow the GNOME or KDE path.
>
> >For example, many things you describe here can be solved elegantly
> with Services.
> >A quick example?
> >In any application which allows text selection (and is a GNUstep or
> Mac app) you can >select a text portion which can be an URL. You go
> into the app menu and will see >services, if you have installed
> Vespucci, our browser, you will see "open URL in >vespucci". It will
> take the selection and open it.
> >This is similar, but not the same, as being able to treat everry URL
> as if it was a "file >type". That is, clicking on an URL opens it in
> Vespucci very similarly as double-clicking >on a PDF file in
> GWorkspace opens it in GSPdf (or the xpdf wrapper). Similar, but not
> >the same.
>
> >Then for the real complex things there are Distributed Objects. Much
> before Java RMI or >ORBIT there was DO. Quite simple to use too. It
> was in OpenStep also the right method >to have inter-thread
> communication. Now apple introduced other means, but it still of
> >course works.
> >You can interact to a daemon, but you can also interact between two
> GUI apps. You can >Separate the Model from the controller up to the
> point where they are on separate >machines.
>
> Great, that's why I contacted Germán(and he contacted you), because
> you both are experts and for me GNUstep came in as an option after a
> research process. Learning it is the next.
>
> >Do not let the current OpenStep look fool you. I use it and i like it
> because I think it is >productive and professional, but the OpenStep
> concept goes beyond the look. Don't >make the mistake of Icaza who
> looked briefly at gnustep, did not understand it and went >over making
> GNOME. We all know where it lead...
>
> I completely understand what you mean, I thought the same when read
> the GNOME history, de Icaza missed the OpenStep power.
>
> >well, maybe you end up with a different interface, but writing a blur
> filter for an imaging >application or a rich text module for a word
> processor will probably itnterest you. As is a >WebView to create a
> browser or a PDF view for PDFs, independently if you want to take >our
> browser or embed it in your "new emacs desktop".
>
> I realize we can have an open channel, while GAP provides a code repo
> for us, GNUkCaH implements a desktop concept feeding back to GAP, this
> stream of bits will benefit everybody here.
>
> >That is something very subjective. Both as far as the GUI paradigm
> (menu style, resize >and buttons, etc) as well as if one prefers shiny
> yummy icons or something terse and >professional. The options are
> open. Theming exists and is being improved. Many things >are already
> now customizable (from Menu behaviour, decoration drawing, colors of
> >various elements... all defaults that can be set). By writing code
> GUi elements can be >changed (a full-blown theme). An application to
> create theme, also by using images, and >changing properties like
> colors easily, is being developed. So many options are open.
>
> Great great great.... what can I say? Things are much much better than
> I thought... heh ;)
>
> PS: Last days we talked about some graphical features in the list, it
> is in spanish so if you cannot understand it, I'll send you a resume
> in english.
>
> Thanks,
>
> William H.
> GNU - Resistencia Digital
>
>
More information about the Trisquel-devel
mailing list