| 1 |
I'm all for doing it this way if everyone agrees. I think it would be a |
| 2 |
decent start, definitely. |
| 3 |
|
| 4 |
I'm gonna head to sleep...it's almost 6am here. But, I want to carry on |
| 5 |
a discussion with you about the cli portage viewer/manager. I have been |
| 6 |
thinking about this one a lot, and want to hear other people's ideas on |
| 7 |
it. |
| 8 |
|
| 9 |
I'm wondering if this will increase the threads on gentoo-dev enough to |
| 10 |
warrant something like an IRC channel to do more of a realtime chat thing. |
| 11 |
|
| 12 |
I'm pretty easy right now as i'm unemployed :) If anyone wants to offer |
| 13 |
suggestions on how to take this step by step, it would be pretty cool. |
| 14 |
Project management isn't my forte. |
| 15 |
|
| 16 |
I like python...so I, myself would suggest a decent python/ncurses |
| 17 |
layout for the cli viewer/manager. I'll start documenting my thoughts |
| 18 |
on this when the sun rises :) |
| 19 |
|
| 20 |
Alright, |
| 21 |
nite... |
| 22 |
|
| 23 |
Brian Harring wrote: |
| 24 |
|
| 25 |
>While I think an X based installer would be nice, I think we might benefit |
| 26 |
>from first doing up a cli based installer first... at the very least, we |
| 27 |
>would need a cli portage viewer/manager, which would be a nice package on |
| 28 |
>it's own... |
| 29 |
> |
| 30 |
>Something also I thought about (and have been playing with), is having |
| 31 |
>essentially a two stage process for the installer- basically everything prior |
| 32 |
>to the chroot, and then everything after. Why? Well, it would be nice to |
| 33 |
>have the first half of the installer handle all the fdisking, untarring, etc. |
| 34 |
>From there, it chroots, emerge syncs and emerge portages, then pulls down the |
| 35 |
>newest version of itself, and runs that. |
| 36 |
> |
| 37 |
>From there, if we wanted we could probably setup some simple equivalent of a |
| 38 |
>quicky binary x server/svgalib for a x based installer. Meanwhile, if we |
| 39 |
>have at least a basic cli installer setup, that would be immediately useful |
| 40 |
>for the cd's, and w/ an update capability, we could push a graphical |
| 41 |
>installer down to the user once we have it ready... |
| 42 |
>Thoughts? |
| 43 |
>~harring |
| 44 |
>bdharring@××××.edu |
| 45 |
> |
| 46 |
>On Sunday 13 April 2003 04:30 am, Derek J. Belrose wrote: |
| 47 |
> |
| 48 |
> |
| 49 |
>>The only real way I can think of is to do some checks on if X is |
| 50 |
>>running, and if it is, use a graphical toolkit for X...if not, use a |
| 51 |
>>terminal based kit like ncurses. |
| 52 |
>> |
| 53 |
>>I like this idea. I should download a liveCD to throw some code on and |
| 54 |
>>do tests. |
| 55 |
>> |
| 56 |
>>Is anyone against pyGTK or something like it? pyQT? wxPython? |
| 57 |
>> |
| 58 |
>>Is anyone against python? :) |
| 59 |
>> |
| 60 |
>>Cedric Veilleux wrote: |
| 61 |
>> |
| 62 |
>> |
| 63 |
>>>Why not simply use gentoo's livecd? |
| 64 |
>>> |
| 65 |
>>>The livecd can boot the user into a fully loaded console or X workstation, |
| 66 |
>>>with all the tools needed. |
| 67 |
>>> |
| 68 |
>>>The installer could be an additional tool on the liveCD system.. Anybody |
| 69 |
>>>knows a GUI abstration toolkit that can generate either terminal based or |
| 70 |
>>>X based interface, depending on what's available at runtime? |
| 71 |
>>> |
| 72 |
>>>This way the same installer could be used if X is not working or can't be |
| 73 |
>>>used. |
| 74 |
>>> |
| 75 |
>>>In both environment (terminal / X), multitasking would be possible so |
| 76 |
>>>experienced users could perform manual tasks while the installer is |
| 77 |
>>>waiting for input.. |
| 78 |
>>> |
| 79 |
>>> |
| 80 |
>>>Just my 2 cents, |
| 81 |
>>> |
| 82 |
>>>Cedric |
| 83 |
>>> |
| 84 |
>>> |
| 85 |
>>-- |
| 86 |
>>gentoo-dev@g.o mailing list |
| 87 |
>> |
| 88 |
>> |
| 89 |
> |
| 90 |
> |
| 91 |
>-- |
| 92 |
>gentoo-dev@g.o mailing list |
| 93 |
> |
| 94 |
> |
| 95 |
> |
| 96 |
|
| 97 |
|
| 98 |
|
| 99 |
-- |
| 100 |
gentoo-dev@g.o mailing list |
Archives