From: Tom Flavel <thomasfl@cogs.susx.ac.uk>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] new guides
Date: Fri Apr 13 06:07:02 2001 [thread overview]
Message-ID: <20010413130555.A15024@tsunx.ctn.cogs.susx.ac.uk> (raw)
In-Reply-To: <3AD6C914.D8CA6C3F@gentoo.org>; from AGottinger@t-online.de on Fri, Apr 13, 2001 at 11:38:28AM +0200
On Fri, Apr 13, 2001 at 11:38:28AM +0200, Achim Gottinger wrote:
>
> We had a discussion about allowing other languages like perl or tcl/tk
> to be used for ebuild. And decided that
> it makes more sense converting stable parts of python code to c++. Once
> it's all c++ we can make modules
> for other scripting languages. I personal prefer perl as a scripting
> language and did not investigate much
> time in learning python. But as long as daniel is the developer of
> ebuild it is his right do choose his
> preferend language for development I think.
> Our biggest problem is still that we can not spend all our time in
> gentoo development as long as we do not have
> sponsors.
>
> There is a install-gui in development that will use qt first, but it
> will be designed in a manner that the gui
> parts are separated from the configuration backend, so it should be easy
> to write ncurses or gtk frontends too.
> But do not expect that stuff next week. :-)
>
Hi,
on a similar note, I remember discussing seperating the backend of portage
from interfaces a while ago, but I think it may have been a bit too early :)
To recap, the idea was to have a C/C++ program listen on a pipe, then have
interfaces (in the language of your choice) do things like
"echo packagename>/thatpipe" - the backend would listen and install the package.
This would mean one could churn out gui's using the wigit tool of personal
prefence, for example, with relative ease. A bouns is that as the protocol
would be simple (basically just a package name/version and what to do with it)
the actual behaviour would be consistent across all interfaces.
- Tom
next prev parent reply other threads:[~2001-04-13 12:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-09 20:56 [gentoo-dev] new guides Daniel Robbins
2001-04-10 22:51 ` pbg1854
2001-04-10 23:11 ` Achim Gottinger
2001-04-11 0:13 ` Gontran
2001-04-11 0:47 ` Achim Gottinger
2001-04-11 1:02 ` Gontran
2001-04-11 1:55 ` Achim Gottinger
2001-04-11 3:08 ` Gontran
2001-04-11 3:16 ` Achim Gottinger
2001-04-10 23:26 ` Achim Gottinger
2001-04-10 23:51 ` Daniel Robbins
2001-04-11 0:19 ` Achim Gottinger
2001-04-11 0:29 ` Daniel Robbins
2001-04-11 0:51 ` Achim Gottinger
2001-04-12 16:14 ` Pete Gavin
2001-04-13 1:41 ` Pete Gavin
[not found] ` <20010413052441.A29405@kabbu.thehutt.org>
2001-04-13 4:07 ` Achim Gottinger
2001-04-13 6:07 ` Tom Flavel [this message]
2001-04-13 6:49 ` Achim Gottinger
2001-04-13 9:21 ` Daniel Robbins
2001-04-13 10:51 ` Pete Gavin
2001-04-16 21:08 ` Jerry A!
2001-04-17 6:28 ` Achim Gottinger
-- strict thread matches above, loose matches on Subject: below --
2001-04-12 17:42 datazone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010413130555.A15024@tsunx.ctn.cogs.susx.ac.uk \
--to=thomasfl@cogs.susx.ac.uk \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox