What Might UserLinux Look Like?

Lucky writes "This story at Linuxworld talks about some of the potential features of UserLinux, as well as Bruce Peren's proposed community desktop project and its potential features. There's some exclusive commentary by Perens there, too."

Comments

Re:UserUtopia?

[Neo-Rio-101]

I think there needs to be more unification and simplification over the way things are installed in , not only Linux, but the BSDs as well.

I think everyone agrees that rpms suck. Most of the good code comes in source tarballs - configurable for any *nix... but this is where the user experience falls apart. What person is going to want to dig out the command line to compile source code, and will he or she know about all the ocnfigure options... and then, will there be dependency issues (or should the source contain the dependencies too?). Then there are the legal issues of bundling dependancies... and then there will be future commercial Linux apps which won't want to include source code.

In an ideal world, packaged installs will be a compressed single file, containing all source code, configurable on any *nix like normal source code EXCEPT that now there's a graphical interface so that setting compile options, creating desktop shortcuts, and "Make clean, make install, make uninstall" now all work under X with a point-and-click.

PLEASE! Will someone serious about standardizing Linux installs do something about this... or desktop Linux will never take off.

Re:could it be?

[Bruce Perens]

Ever think about why the Safari web browser in OS/X is derived from Konqueror? All of those people who were being paid saw how excellent the work of the people who weren't getting paid was.

I had this same argument with Steve Jobs in 1999. Today we have more people on the Linux desktop than on OS/X, and Steve stood in front of a slide saying "Open Source, We Love It!" at MacWorld.

Bruce

Re:Desktop intergration...

[some guy I know]

What I'd like to see would be a site dedicated to collecting feedback on what Linux users (old and new alike) would like to see created or improved.

The problem with that is that many Mac users would want one mouse button, many MS-Windows users would want the <CTRL+C> /<CTRL+V> copy/paste, etc.
You can't accomodate them all with a single UI.

What is really needed is a virtual layer between the (G)UI and app that would allow GUI "themes", similar to the way that KDE and GNOME have themes for their WMs.
For example, say that I am using a program that displays various objects that can be moved, copied, etc.
Rather than receiving events like <KEY C with CTRL modifier> or <MB1 with mouse coord> , the program would receive events like <COPY> or <MOVE with delta/coord> .
Then, the GUI theme that I was using would determine what keys/mouse movements generate what events.
Some programs already allow users to customize keyboard shortcuts and menus.
This would be like that, except that, instead of customizing per-application, it would customize across all applications.

The problem is determining the domain of events that the virtual layer would support.
Operations like copy, paste, and move are easy (and have already been done for things like text boxes); file open/save operations are semi-standard in that many apps use <CTRL+O> and <CTRL+S> (but not necessarily customizable, and certainly not globally); other, less common operations (e.g., drawing a line from point A to point B, adding to or subtracting from the current selection, etc.) could be handled using some sort of modular system (ala XML XPointers, etc).

Re:Consistency and control

[cca93014]

Mod this guy up.

The only way the Linux desktop is going to become consistent, and not only from a GUI perspective but from a config file and usability, and application integration (i.e. clipboard) perspective, is for EVERY application that is available for UserLinux to filter through a single point of contact.

This group would then standardise (with regards to the GUI, config files etc) EVERY application that is submitted.

I dont see any other bullet proof solution. It would be a ton of work (and really shitty work at that) but it *would* work.

It's basically what distros are doing already with their different package management implementations, but taken to the next level; i.e. instead of making sure the package compiles/binary is not left with missling libs, you make sure of not only that but also the applications all have the same file dialog, windowing toolkit etc.