#47 prepackaged GUI image

[Anonymous]

The slashdot discussion (http://developers.slashdot.org/developers/04/04/12/211236.shtml?tid=106) shows quite well that many users would find it easier if there was a prepackaged version that comes with all the necessary programs and configs to easily run a UI (i.e. X11/KDE) version on top of coLinux.

Something like this would preferably come with the necessary X server for the windows side of things and be sufficiently preconfigured

[Nobody/Anonymous]

Logged In: NO

see "andLinux"

however, usability could still be somewhat improved for users with a non-nix background, in particular the whole setup process should either be more intuitive or simply provide some more GUI frontends, i.e. by allowing the most common actions to be directly done from the executables via UI means, rather than requiring users to pass lots of cryptic options via command line parameters. In this context, it would already be a significant improvement if the most basic and relevant parameters could be configured via some sort of GUI frontend, be it embedded or not, so that running a process without REQUIRED parameters automatically brings up a dialog for users to configure the most important parameters, and optionally save them as startup profiles, so that they may next time select a startup profile or create a new one.

Similar to how firefox starts actually: provide a way for customization, preferably using lots of nifty tooltips and explanations and once a user has a working config, enable them to save and reuse configs

[Nobody/Anonymous]

Logged In: NO

something like this would probably be best implemented as a separate, standaline "profile manager", so that creating/editing and deleting profiles can be done via this app, and starting a profile would only entail passing the stored parameters to the corresponding binaries, this would keep the overhead to a minimum.

[Nobody/Anonymous]

Logged In: NO

thinking about it, the most promising approach would probably be to simply implement this totally separate, using a scripting language and a GUI toolkit, i.e. something like python or ruby with GTK/QT bindings. This way, it would not unnecessarily affect any of the existing code, would be very much straight forward and also flexible and easily extendsible for future changes

[Henry N.]

Logged In: YES
user_id=579204
Originator: NO

If somebody has knowledges about Python, then here are some of GUI scripts for coLinux configuration, that has to be finish:

http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/user/configurator/

It's very old. First needs to remove the outdated XML from that.

[Nobody/Anonymous]

Logged In: NO

Python is awesome, i know, but why not C#?

Mono is distribuited with major linux systems and on windows you're fully integrated with .NET! I think that a lot of users are windows based so a fully native interface and a fully integrated application can do better than a python application

Another really important stuff is that with .NET you can easely build two interfaces and load the preferred at startup time simply checking the operative system ... with the interfaces that relies on a set of functionalities implemented in a backend

[Nobody/Anonymous]

Logged In: NO

Just a note to the previous comment ...

if necessary you can use python too for development using ironpython!

[Nobody/Anonymous]

Logged In: NO

I think, this frontend would be Win32-specific in any way, so it really doesn't matter what language is used for implementation, however it may be easier to favor an implementation language that is commonly and widely known within the community of potential contributors, so that future maintenance of such a frontend would not be limited to an unnecessarily small group of contributor who are sufficiently familiar with the corresponding language. Using a scripting language such as Python or Ruby on the other hand, brings the added advantage that potential contributors/maintainers of such a frontend would not necessarily have to install any complex dependencies (think IDE, compilers, runtime libs). Most mainstream scripting languages are well-supported on a rather wide number of platforms, unlike C# development tools, which still require numerous non-standard dependencies to be properly installed and set up for each platform individually.

[Nobody/Anonymous]

Logged In: NO

"
Most
mainstream scripting languages are well-supported on a rather wide number
of platforms, unlike C# development tools, which still require numerous
non-standard dependencies to be properly installed and set up for each
platform individually.
"

Sorry, but this isin't true! To develope using C# you can use mono to compile the stuff you write on all supported platform, windows too. You can write it with any ide/rad you like, naturally there are tools to do like monodevelop on linux and sharpdevelop/visual studio (express) on windows.
This is the same for any scripting language: you need the runtime to execute the script and any editor to write the stuff

I didn't see any kinda of non-standard dependencies:
- On windows, you have the runtime simply doing updates
- On linux, many major distros has it ((open)suse, ubuntu, fedora, gentoo)

Another example: if you use GTK you need binding ... like any other programming language that doesn't resides directly on the libraries (note: technically you can compile in the bindings using a couple of mono tools)

[Nobody/Anonymous]

Logged In: NO

this is a rather academic discussion, those who tackle this idea are going to decide what tools and languages they use

[George P Boutwell]

The original author and I had a few discussions about this back when we first started the port to 2.6 kernels... The current developers may have different opinions, but I tend to agree with what was decided then. To summarize:

coLinux project's main purpose is to provide the patched kernel and host machine drivers necessary to accomplish fast (near native performance) virtualized Linux. With the few developers working on the project is is completely unrealistic to expect or extend this purpose beyond that. Focusing on that, it was decided that coLinux as a project would not go out of it's way to build and support an installer which included everything for graphical images, this in turn allowed several projects to be built on coLinux that servered that purpose similar to that of andLinux (used to be one called Colonize or something like that too but couldn't find it on Source Forge today when I looked).

Henry, you think this choice to continue to focus on our main goal of providing the kernel and drivers for a fast virtualized linux is the right one, then you can probably consider this request resolved.