Contributor spohl - Ubuntu brainstorm

Ubuntu QA:

Blog

Brainstorm

Package status

The Ubuntu community has contributed 22823 ideas, 138726 comments, 2639112 votes

All more
Projects more
Global categories more
- Accessibility
- Documentation
- Education
- Gaming
- Graphics
- Hardware support
- Installation
- Internet & Networking
- Look and Feel
- Marketing
- Multimedia
- Office
- Programming
- Quality
- Security
- Server
- System
- Usability
- Others

Idea sandbox

Popular ideas

Ideas in development

Implemented ideas

Contributor spohl

Titlebar and menubar are wasting too much vertical space.

Written by sicofante the 8 Mar 10 at 07:05. Related project: Gnome. Implemented

The newer themes for Lucid make no colour distinction between the menubar and the titlebar. Check any picture of a window with the new themes for Lucid and you'll see the amazing waste of vertical space.

Also new in these themes is the feature that a window can be dragged by both its titlebar and its menubar. Makes sense, since it's a big fat single colour area.

Widescreens are more and more 16:9, which makes them vertically shorter. Vertical space is becoming more and more precious.

Isn't it time to merge both the titlebar and the menubar?

446
votes

Selected solution (#1): Merge titlebar and menubar in a single bar

Written by sicofante the 8 Mar 10 at 07:05.

Merging both bars in one will save vertical screen space and won't affect the way we use the windows now.

There's actually no need for more than the three buttons (minimize, maximize, close) since the window menu can be accessed by right clicking on the window's title or no-menu area.

When the window is too narrow for displaying the full title, we can provide a tooltip showing it in full. Also, developers would be careful by choosing what to display as a window title. Name of the application is usually unnecessary (we know what the application is, we launched it...) and usually only the document name is important.

How to technically doing it is out of the scope of this idea (I'm not a developer). Maybe it's just about removing the titlebar altogether (or reducing it to 0 pixels) and add the title and control buttons to the menubar.

-75
votes

Selected solution (#2): Merge title and menu bar + remove status bar too

Written by Klau3 the 10 Mar 10 at 23:25.

Merge title and menu bar like on the screenshot . To see the menu again the user has to click on the “Menu/Options” button in the left corner. Also remove the status bar and replace it by a mouseover information that will appear after a half second – like it is in Lucid right now for the Places menu.

-55
votes

148
votes

Selected solution (#4): Decrease the height of the title bar, ala Google Chrome

Written by Mirek2 the 14 Mar 10 at 14:47.

As someone who has tried a prototype of this, let me tell you that with small windows, small screens, or large menus, it's a nightmare trying to move windows around, if possible at all.
I think Chrome has a good compromise: remove the text from the title bar and make it a lot thinner, but still keep the height big enough so that one can easily move and resize windows without accidentally opening up menus instead.
With maximized windows, the title bar should merge with the menu bar completely, as one can't move a window in maximized state and as it suits the Fitts law nicely (that is, if you remove the top panel in Ubuntu).

-37
votes

57
votes

Selected solution (#6): Be more original, and re-work the paradigm

Written by isantop the 16 Mar 10 at 00:22.

Think something similar to UNR. Remove the title from the active window, and display it in the top panel instead, which has wasted space on most systems by default. Long titles can be truncated like in the task list.

Make the titlebar thicker, and put the menubar in it, leaving space to grab and drag, like solution 4. If a windows is narrow, truncate the menu and place a "More..." button, similar to solution #1

-24
votes

Selected solution (#7): GnomeShell? and maybe overlapping?

Written by LukeM33P the 25 Mar 10 at 01:30.

There are a few points I'd like to make:

Most widescreens are 18.5 inches or greater. Many are also high-resolution. Lower-resolution screens are often 4:3, where this is not a problem and the resolution is the problem.

For the few places where the scenario at top makes sense (auto-detection on install would be nice for this), button sizes should be reduced, text should be reduced, and the bottom panel shrunk in height.

Next in line, we realize the top panel is mostly indicators which theoretically have popups which will appear over the windows. The links on the upper toolbar are quick-launch-like, and the drop down menus are mostly unnecessary when applications that are screen-filling are necessary. So, the top menubar is always behind any windows in a full-screen mode, but retains its solid shape for smaller windows. To avert frustrations when trying to use the full screen with multiple applications, lock points on the screen (user customizable) should allow an undefined number of applications to lock to a full screen view (taking up the full screen as a group, moving as a normal window would, or locking AeroSnap-esque, based on preference or per-window setting). Other non-full-screen applications, of course, would still be visible.

Possible solution.

[...]

Edit: Forgot to mention GnomeShell. GnomeShell will make the top bar superfluous. Look up GnomeShell if you want more details.

12
votes

-4
votes

Selected solution (#9): Create an applet to optionally show title bars in a panel

Written by Liso22 the 27 Mar 10 at 18:37.

I've been dealing with the same problem for some time, and mostly considering I use awn that takes more or less thrice the space of a regular panel and that I have a laptop screen. I think the solution should be to add an optional applet which will normally show the regular Ubuntu menu bar and when an application is running it will switch to show the Ubuntu quick menu icon and the application title bar, this will be totally optional so it can hurt nobody and will benefit both the users who prefer a windows like behavior than those who prefer a mac interface. This is the mockup of how it should look when an application is running and the space that will be saved.

[url=http://www.freeimagehosting.net/uploads/134b0462fd.png[/img][/url]">http:/ /www.freeimagehosting.net/][img]http://www.freeimagehosting.net/uploads/134b0462 fd.png[/img][/url]

4
votes

Selected solution (#10): Create an applet to optionally show title bars in a panel

Written by Liso22 the 27 Mar 10 at 18:49.

I've been dealing with the same problem for some time, and mostly considering I use awn that takes more or less thrice the space of a regular panel and that I have a laptop screen. I think the solution should be to add an optional applet which will normally show the regular Ubuntu menu bar and when an application is running it will switch to show the Ubuntu quick menu icon and the application title bar, this will be totally optional so it can hurt nobody and will benefit both the users who prefer a windows like behavior than those who prefer a mac interface. This is the mockup of how it should look when an application is running and the space that will be saved. (I don't know how to make the image show I'll just paste a couple of links click any)

http://i40.tinypic.com/2eeh7v7.jpg

http://www.freeimagehosting.net/image.php?134b0462fd.png

http://www.freeimagehosting.net/image.php?134b0462fd.png>

http://www.freeima gehosting.net/uploads/th.134b0462fd.png alt="Free Image Hosting by FreeImageHosting.net">

3
votes

-13
votes

-10
votes

Selected solution (#13): Menubar hides behind titlebar & shows on mouse hover, and toolbars dock under

Written by geoff.m the 31 Mar 10 at 01:40.

1. The titlebar and menubar are merged. we need to see always the window titles in order to see quickly what they are at all times, but not the menus. menus appear over windowtitle when mouse hovers around it.

2. The toolbars also need to be accessed often, but they have little need to be seen all the time. therefore they could just dock under the titlemenubar.

2.a. in the case of browsers, the url could appear next to the window title

Then we would have 1 bars instead of 3, saving about 80 pixels in height that can be now used for actuel software and content space.

-11
votes

Selected solution (#14): Take a clue from The Amiga: Right click and hold activates menu

Written by Duncan J Murray the 1 Apr 10 at 20:11.

Anyone who has used Workbench would remember the right-click and hold would bring up the menu over the title bar.

To implement this into Ubuntu I would suggest that the menu bar is removed, but would appear, temporarily replacing the title bar when the right mouse button is clicked and held (with the selection being made on the release of the right mouse button).

An alternative would be that a single right click would transform the title bar into the menu, and then you can navigate the menu as you normally would, left clicking to select.

This method does not add any extra key presses or mouse clicks in accessing the menu, which I think is crucial, but will save one horizontal bar of vertical space.

63
votes

-5
votes

Selected solution (#16): Move the top panel to the left side of the screen

Written by jerome.bouat the 4 Apr 10 at 14:08.

What about putting the current top panel on the left on the desktop ?

The "Applications", "Shortcuts" and "System" menu could be replaced by icons.

The vertical position of panel at the left can lead to less area consumption than the top position of the same panel.

Currently, a 16/10 form ratio screen makes 17/10 form ratio of the maximized windows.

Therefore the panel at the left would make the maximized windows form ratio like ~16/10 instead of 17/10 currently. The horizontal form ratio is mostly used for watching movies in fullscreen. Thus the ~16/10 ratio of the maximized windows would make the use of the firefox and
openoffice easier but not impact the other applications.

1
votes

Selected solution (#17): Remove the menu bar in Nautilus entirely and add proper buttons instead

Written by la_serpe the 7 Apr 10 at 22:51.

Think about it for a moment. How often do you use Help and About menu for instance? What about the Tabs menu? Isnt it easier to use mouse? Bookmarks and Go have basically the same function. Instead of File you can simply right click on the blank surface. This redundancy isn't only annoying, but it's also confusing. It has been inherited from Windows 3.1 I guess. Let's abandon it finally!

0
votes

Selected solution (#19): a compiz effekt to roll in, roll out titlebar plus merge menu- and titlebar

Written by wenex the 7 Jul 10 at 19:47.

a compiz effect that "hide" titlebar, so it looks like the other boarders. When the mousepointer is over the top window boarder, it expands to the titlebar.

give some options to choose hide and unhide delay and how it scales, if its a maximized window ...

merge titlebar and menubar into a single bar with the option to have a menu button in the titlebar.

0
votes

Selected solution (#20): Hide/Unhide title bar automatically.

Written by Lachu the 19 Dec 10 at 10:13.

Titlebars should been hidden, when mouse cursor are above of active/foreground window(having keyboard focus). It should appear again, when some button(like alt) pressed or mouse cursor are outside foreground window. Titlebar isn't part of active window(let's say).
Also titlebar of active window would appear when mouse react on top-corner of window.

In most times we don't need a titlebar at all. We've used it only to move window around or changing active window.
Dialog(like progress dialogs) contains a lot of useful information about which progress it observe... Conclusion is: we need a titlebar only to change active window and drag window around.

When window is maximized we should have top corner displayed, but it will be very small. When window is maximized there's way to display titlebar. On window is foreground we only move cursor at top of it or outside and we can drag it. When mouse is placed outside foreground window, we can also see titlebar of other window.

1
votes

See the 39 comments or propose a solution (latest comment the 8 Sep 12 at 07:42) >>

Engage DeviantArt for Ubuntu theme competition

Ubuntu

In :
Priority :	Undefined
Definition :	Pending Approval (Needs guidance)
Implementation :	Good progress
Assignee :	Mike MacCana

Written by mikemaccana the 29 Feb 08 at 01:19. Global category: Look and Feel. Won't implement

There is a wide community of online artists capable of creating brilliant, unique artwork.

heading: Get your artwork on 10 million desktops

Ubuntu, the world's most popular Linux distribution, needs a new theme. The winner will appear in the default desktop of Ubuntu 8.10.

We're looking for original wallpapers, that match Ubuntu's color palette. You entry should also include a suggested combination of application, icon, and window themes. These can be existing themes, or your own original works - you only need to submit a wallpaper to win.

Work must be CC licensed, and be openable in either Inkscape or Gimp (rest of criteria continues)

Submit your works to DeviantArt and include the words [Ubuntu810].

Good luck!

Developer comments

At this point in time it is unclear as to whether we can realize something like this. In any case we cannot promise to include anything as default without having already seen it. This might be a good way to find alternative wallpapers to also include on the CD and/or universe as an extra package.

4100
votes

9
votes

Solution #2: Ubuntu picks the winners

Written by bukzor the 9 Apr 11 at 19:38.

@Developer: If you pick the winner of the contest, then surely you will have seen it beforehand... This can easily be done. Please reconsider. For a great reference see the recent collaborative competition hosted by TF2 and Polycount.org ( http://www.polycount.com/team-fortress-2-polycount-pack/ ). This created valuable assets for TF2, prestige for Polycount members, and great buzz for both.

See the 137 comments or propose a solution (latest comment the 19 Feb 12 at 02:53) >>

System Monitor Difficult to Find

Written by fluteflute the 28 Feb 08 at 16:55. Global category: System. Implemented

If apps crash in linux most users have no idea where to look for the task manager.

On Windows pressing either Ctrl+Alt+Del or Ctrl/Shift/Esc brings up the Task Manager.

1689
votes

39
votes

28
votes

15
votes

7
votes

Selected solution (#5): Addition to #4: Extend Shutdown-Dialog with "Restart X"-Button

Written by dei the 27 May 09 at 10:09.

The 60 seconds Countdown in the Shutdown-Dialog (brought up by ctrl+alt+del) should be Changed to Restart X. There should be a appropriate Button for it too.

If a process loops the user pressing Ctrl+Alt+Del can try to restart X, start the sysmon or reboot. If X doesn't react the Countdown will restart it automatically.

-4
votes

See the 50 comments or propose a solution (latest comment the 15 Aug 11 at 08:26) >>

Installing software is still difficult, and no mechanism exists for paid apps

No information about this blueprint
Information is updated every 5 minutes.
Please wait till the next update.

Written by MrBoB the 9 Mar 09 at 20:47. Related project: Add/Remove program dialog. Implemented

Installing software on Linux has gotten much easier over the years, but can still be confusing. Most users don't know what synaptic is, and have no interest in typing "apt-get blah blah" Additionally, because there is no system in place to charge for software, commercial venders cannot provide software for Linux in any convenient manner.

With a little tweaking, Synaptic ( or Add/Remove Software ) could be rebranded to better resemble a free "App Store" and with a little more tweaking, a system for allowing paid apps to be installed could be provided to the user.

-124
votes

Selected solution (#1): Rebrand Synaptic to "App Store" and allow paid packages.

Written by MrBoB the 9 Mar 09 at 20:47.

Recent advances in the power of smart phone OS's notably Google's Android, Apple's iPhone, and RIM's Blackberry, have lead to the adoption of "App Stores" which users are now very comfortable with. The "Add/Remove Program" dialog already provides this functionality, but could be better focused on the App Store concept.

Additionally, these app stores provide a mechanism for individual programmers to be nominally paid for their work, and for the owner of the app store to take a cut of the profits, providing a revenue stream. If the apt-get protocol could be modified to provide a method for installing paid applications, I believe that we would see more interest from both programmers and software vendors.

Note that I am not advocating that people should pay for existing open source apps. What I am suggesting is that there are applications that would become available on Linux (Adobe Photoshop?) if there was a system in place to install them for a fee. Something like Firefox or gThumb would a be "Free App" in the app store.

166
votes

12
votes

Selected solution (#3): Create unified file format to store repo-information

Written by andrew.p the 19 Mar 09 at 22:47.

Create openable file format (non-executable, e.g. not bash script) with repository information (and a link to ppa key) to save and import it easily. If you want to add ppa or 3-rd party application like Skype you install such file instead of adding a repo or installing a single package (this is not a good way of installing at all).
The extension can be .3ri (third-party repository information/installation) or something relative.

Commercial vendors can sell their software from their websites. The question is how they can copy protect their software and how to guarantee that such repos will not alter essential components of the system. While the first is not our problem, the second could be implemented as repository trust DB.

-1
votes

30
votes

-25
votes

Selected solution (#6): A system for paying for applications from Add/remove

Written by Menti the 22 Mar 09 at 11:07.

This system is thought to make it easier to test and later pay (or donate) for open source applications.

1) Show price tag
You go to Add/Remove and you find an application like:
_____________________________________________
Time Waster
Recommended price 5$
_____________________________________________

2) Buy or test
Either when you select the application, or when you click |Apply|, a popup appears:
__________________________________________________________
You have selected "Time Waster" for installation
What do you want to do with this application?
( ) Buy
(*) Test
I want to be warned after [ 7 ] days testing "Time waster"

[...]

| Accept |
___________________________________________________________

You select either buy or test. The "warning after 7 days" line only applies to Test and will not appear if you select Buy. The brackets are an input field where you can write the value you prefer, 7 is the default.

3a) If you select Buy
The payment process will start. This can be done either by taking you to the developer's page, by taking you to an Ubuntu website where payments to every developer are centralized, or from Add/Remove itself. I guess it will depend on where users feel more comfortable writing their credit card number.

3b) If you select Test
The software will install normally, with no more questions.

4) Warning
7 days after installing the software for testing, the following popup appears:
______________________________________
You have tested "Time Waster" for 7 days
What do you want to do?
| Buy | | Keep | | Remove |
______________________________________

This popup can appear either 7 days after installation, or the first time you launch the application after 7 days have passed.
The buy button would take you to the payment process. Keep would just keep the software in your computer without paying, and remove would uninstall it. This would be the first and last warning ever about this.

For closed source paid apps, the Test option would not be available.

This system is thought to make it easier to test and later pay (or donate) for open source applications.

1) Show price tag
You go to Add/Remove and you find an application like:
_____________________________________________
Time Waster        
Recommended price  5$
_____________________________________________

2) Buy or test
Either when you select the application, or when you click |Apply|, a popup appears:
__________________________________________________________
You have selected "Time Waster" for installation
What do you want to do with this application?
(  ) Buy
(*) Test
     I want to be warned after [ 7 ] days testing "Time waster"

| Accept |
___________________________________________________________

You select either buy or test. The "warning after 7 days" line only applies to Test and will not appear if you select Buy.  The brackets are an input field where you can write the value you prefer, 7 is the default.

3a) If you select Buy
The payment process will start. This can be done either by taking you to the developer's page, by taking you to an Ubuntu website where payments to every developer are centralized, or from Add/Remove itself. I guess it will depend on where users feel more comfortable writing their credit card number.

3b) If you select Test
The software will install normally, with no more questions.

4) Warning
7 days after installing the software for testing, the following popup appears:
______________________________________
You have tested "Time Waster" for 7 days
What do you want to do?
| Buy |        | Keep |   | Remove |
______________________________________

This popup can appear either 7 days after installation, or the first time you launch the application after 7 days have passed.
The buy button would take you to the payment process. Keep would just keep the software in your computer without paying, and remove would uninstall it. This would be the first and last warning ever about this.

For closed source paid apps, the Test option would not be available.

3
votes

Selected solution (#7): Packages for commercial software

Written by mronkko the 24 Jun 09 at 19:44.

Introduce packages that contain alternative installers for commercial software. This kind of package, when installed, would help installing commercial software and when uninstalled, would remove the same software. The user would just need to download a file containing the software or insert an installer CD. Then, instead of using the installer provided by the commercial software vendor, the user would install the ubuntu package for this software.

When this kind of package is installed, it would scan /media and common download locations for an installer file or archive of the commercial software that this package would install. If not found, the installer would ask the user to give a location of the original installer. When the software is found, the package would install all dependencies, install the commercial software from the media or file provided by the software vendor, apply possible workarounds that are required, write appropriate .desktop files, and register file associations.

The same system could be used to install windows applications through wine (somewhat similar what CrossOver does)

13
votes

Selected solution (#8): Improve "Add/Remove" software

Written by jackmcslay the 11 Aug 09 at 22:08.

For starters, it should have as default to display all apps instead of only the Canonical-supported ones. Canonical-supported apps could be identified by the ubuntu logo like they do on synaptic.

More information about the applications should be provided, such as screenshots, and wikified descriptions so users can help translating texts and describe the softwares further.

Lastly, With the large ammount of softwares in the repos, subcathegories would be VERY welcome.

14
votes

Selected solution (#9): Make it easy to add repositories

Written by lordmetroid the 27 Aug 09 at 11:48.

Users are already familiar with going to the website of the developer to download and install the software. Have a plugin interface for the Ubuntu app store that allows non-commercial as well as commercial software developer to add their repositories through a simple click on a link from the browser much like downloading the software.

This would maintain the users freedom over what software the user would want in the repositories. Without the control of an oppressive dictating centralized governing body that other app stores are subjected to.

2
votes

Selected solution (#10): Decentralize payment for commercial software

Written by lordmetroid the 27 Aug 09 at 12:03.

There are already pay-services available, and commercial software developers that sell their software from their own websites already have their preferred solution of payment arrangements implemented on their website.

When installing a commercial software using the Ubuntu app store launch the web browser and direct the user to use the already existing facilities arranged by the software developers themselves to purchase the software. This will further ensure the freedoms given in Solution #9 for users to decide what software they wish to have in their repositories and eliminate any need for a centralized governing body that other app stores are subjected to.

0
votes

Selected solution (#11): MojoSetup support

Written by mjau the 27 Aug 09 at 13:43.

Ryan C. Gordon's MojoSetup, though still in development and not yet complete, is getting increasingly popular for commercial games. MojoSetup itself is open source, and can produce self-contained installers that can be run on any system to install the associated game.

MojoSetup installers are written, or configured, entirely using Lua scripts. All scripts, files and other data (the archive) can then be zipped up (though other compression methods may also be supported) and concatenated onto the main MojoSetup executable to make a self-contained installer. (MojoSetup can also read files from the local filesystem if there's no attached archive, but downloaded installers are practically always self-contained for obvious reasons.) When such a self-contained installer is run, the executable first opens itself as an archive, decompresses the installation scripts, runs them and shows the UI and such, decompressing files as needed during the install. (This avoids the massive pre-decompression step that made eg Loki Setup so slow to start up.) It also supports online installation, etc.

See http://icculus.org/mojosetup/

Now, to the point: Everything that a MojoSetup installer does is written in Lua scripts, and scripts and installation data are easily available simply by opening the installer executable as a zip file. Ubuntu could simply provide an alternate executable to open and run MojoSetup installers, with its own implementation of the MojoSetup calls that integrates the installation process with Ubuntu's own package manager. Since MojoSetup config files also include both a vendor, package id, and version number, updates could also be handled this way.

[...]

With this setup, users would download MojoSetup files (or install from CDs, etc) just like a normal file, in the regular way -- no need for a centralized repository. On Ubuntu, the system would associate the installer with a standard mime-type or extension, so that the installer could (optionally) automatically start in Ubuntu's version of the installer when the download is complete, avoiding the whole chmod +x circus, providing the end user with a smooth installation experience =)

Of course, such MojoSetup installers would still be self-contained, so they'd still work fine on non-Ubuntu systems, like they do now. Developers would have just one package to maintain, and in fact wouldn't even have to be aware of Ubuntu's special handling for it to work (though it couldn't hurt either).

There's a few problems with this too, though. First of all, as I mentioned, MojoSetup is not yet complete, and currently lacks some features like eg a standard way of installing desktop menu entries (though support for this is planned). Also, relying on a mime-type for MojoSetup installer detection can be unreliable since developers might not have control over the web-server providing their downloads (commercial software may be hosted by the payment processor!), and there's not really a standard extension for MojoSetup installers currently (.mojosetup has been proposed, but this is very long .. personally I've used .mojo.run or just .run (also used by Loki/makeself). I've also seen .bin, or even .sh (which is familiar for Loki users but very misleading since MojoSetup installers are not shell scripts)). They could perhaps be identified by looking for executables with zip files concatenated and see if there's a MojoSetup style config file inside, but a standardized filename extension would probably be better.. Also, since MojoSetup installers are real executables, marking an installer executable and running it on an Ubuntu system would still run the actual executable in stead of Ubuntu's version -- this could be fixed by having the embedded MojoSetup executable check for the presence of an overriding executable (MojoSetup already has support for alternate executables, currently used eg for running a 64-bit installer from a 32-bit executable on a 64-bit system, so this may in fact already be supported).

(Disclaimer: I've no real association with MojoSetup, except I really like it and have used it for installers for some commercial games. I've also contributed some small patches now and then. If this solution is chosen, I'd definitely recommend cooperating with the creator of MojoSetup, Ryan Gordon. He can be reached via the link above.)

MojoSetup installers are written, or configured, entirely using Lua scripts. All scripts, files and other data (the archive) can then be zipped up (though other compression methods may also be supported) and concatenated onto the main MojoSetup executable to make a self-contained installer.  (MojoSetup can also read files from the local filesystem if there's no attached archive, but downloaded installers are practically always self-contained for obvious reasons.)  When such a self-contained installer is run, the executable first opens itself as an archive, decompresses the installation scripts, runs them and shows the UI and such, decompressing files as needed during the install.  (This avoids the massive pre-decompression step that made eg Loki Setup so slow to start up.)  It also supports online installation, etc.

See http://icculus.org/mojosetup/

Now, to the point: Everything that a MojoSetup installer does is written in Lua scripts, and scripts and installation data are easily available simply by opening the installer executable as a zip file. Ubuntu could simply provide an alternate executable to open and run MojoSetup installers, with its own implementation of the MojoSetup calls that integrates the installation process with Ubuntu's own package manager.  Since MojoSetup config files also include both a vendor, package id, and version number, updates could also be handled this way.

Of course, such MojoSetup installers would still be self-contained, so they'd still work fine on non-Ubuntu systems, like they do now.  Developers would have just one package to maintain, and in fact wouldn't even have to be aware of Ubuntu's special handling for it to work (though it couldn't hurt either).

There's a few problems with this too, though.  First of all, as I mentioned, MojoSetup is not yet complete, and currently lacks some features like eg a standard way of installing desktop menu entries (though support for this is planned).  Also, relying on a mime-type for MojoSetup installer detection can be unreliable since developers might not have control over the web-server providing their downloads (commercial software may be hosted by the payment processor!), and there's not really a standard extension for MojoSetup installers currently (.mojosetup has been proposed, but this is very long .. personally I've used .mojo.run or just .run (also used by Loki/makeself).  I've also seen .bin, or even .sh (which is familiar for Loki users but very misleading since MojoSetup installers are not shell scripts)).  They could perhaps be identified by looking for executables with zip files concatenated and see if there's a MojoSetup style config file inside, but a standardized filename extension would probably be better..   Also, since MojoSetup installers are real executables, marking an installer executable and running it on an Ubuntu system would still run the actual executable in stead of Ubuntu's version -- this could be fixed by having the embedded MojoSetup executable check for the presence of an overriding executable (MojoSetup already has support for alternate executables, currently used eg for running a 64-bit installer from a 32-bit executable on a 64-bit system, so this may in fact already be supported).

(Disclaimer: I've no real association with MojoSetup, except I really like it and have used it for installers for some commercial games. I've also contributed some small patches now and then.  If this solution is chosen, I'd definitely recommend cooperating with the creator of MojoSetup, Ryan Gordon.  He can be reached via the link above.)

0
votes

2
votes

Selected solution (#13): Include Listaller support to AppCenter too

Written by Matthias the 28 Aug 09 at 17:18.

The Listaller project created a management system for applications too.
The next Listaller version will contain an API which will allow distributors to add Listaller functions to their tools.
It would be great if I could install IPK packages with AppCenter too, also Listaller's feature to manage Autopackage and LOKI installations is very nice.
Talk to the developers to make the application API stable for Ubuntu 10.04!

(This would fix the "Include MoJo-Support", "Packages for commercial applications", "Integrate CNR.com" and "Include One Click Install support" requests too!)

http://listaller.nlinux.org

6
votes

Selected solution (#14): Easyly undo and redo actions

Written by ubuntuuser1 the 1 Sep 09 at 20:18.

There should be an option for undo and redo certain installations...
Especially for new and curious users who want to test software but don't know the effect an installation brings it would be great if they could easyly bring there system in a former situation...

as far as i know current synaptic just lists packages that were installed and the time. one has to undo an installation "by hand" by searching and removing the packages. this takes a while an isn't very efficient...

See the 19 comments or propose a solution (latest comment the 22 Mar 11 at 08:16) >>

Push for partnerships with other hardware vendors

Written by Veejay the 28 Feb 08 at 14:41. Global category: Others. Implemented

Given the success (as far as I know) of your Dell partnership, please do everything possible to seek alliances with other vendors, as it will reinforce the idea that Ubuntu is a viable alternative to other operating systems and will provide better hardware support for current Ubuntu users.

Dell is offering new models based on Ubuntu (recently the XPS M1330 in a few countries), proof that the business model makes sense.

Developer comments

We have an active partnership program and are open to discussions with hardware vendors. See: http://www.ubuntu.com/partners/hardwareprogramme

3026
votes

See the 29 comments or propose a solution (latest comment the 23 Oct 09 at 08:20) >>

no info when trying to execute files without permission

Written by spohl the 15 Feb 09 at 12:04. Related project: launchpad.net. New

If one gets a binary file and tries to start it with a doubleclick for instance, nothing happens because there is no permission to execute the file as a program. Most people, especially the one new to Ubuntu don't execute each application or downloaded file in the terminal. Thus they get no response after doubleclick when there is no permission to execute.

It would be nice to have a pop-up window in this case, which gives a few options or information.
There should be the possibility to directly give the file the permission to execute and furthermore to let it run in the terminal.

For example, someone downloaded googleearth.bin, he can click as much as he wants. This dialog could be very helpful for new Users.

Another example: You wrote your own program, sending it to a friend, he cannot execute without instructions.

I also did a blueprint on launchpad, some time ago:
https://blueprints.launchpad.net/ubuntu/+spec/execute-dialog

13
votes

Solution #1: add pop-up windows on execution

Written by spohl the 15 Feb 09 at 12:04.

The software somehow has to recognize that there is no permission to execute.
If one has an executable text file for instance, there is already such a pop-up window that gives options for either display the text or run the file in terminal. Therefore I cannot imagine it to be too difficult to do it in a similar way for not executable files

8
votes

Solution #2: At least provide SOME feedback as to why nothing happened.

Written by r0g the 18 Feb 09 at 19:08.

Even if you buy the security argument in the comments section (which is bogus*) there is no excuse for actions just failing silently, that's just terrible HCI.

At the very least when a file is double clicked and there is no appropriate action that can be taken a dialog should appear explaining this to the user.

I really don't have a problem with a dialog that offers the user the chance to mark the file as executable and launch it. Several devs have mentioned this is a security problem but it only is if you implement it stupidly...

*Clearly if you can detect this situation you can open a dialog with several options. Naturally one of those options could be to mark the file as executable and run it. At this point it is PERFECTLY POSSIBLE to include...

A) An explaination of what executable means
B) A stern warning that this could hose your system
C) A prompt for your password
D) A system permission check

If a user presses on regardless of these things and the admin has given that user the appropriate permission (note I am not saying what the default should be here) then that's their problem.

[...]

Apropos of this recurring argument I really don't understand the mentality of people who object to the existence of a graphical analog of a process you would otherwise have to carry out on the CLI. Is the CLI mean to appear more sombre and serious somehow? Maybe we could get round that in the graphical instance by playing some tense, brooding classical music and using some dramatic 3D lighting effects every time an escalation of privilege was required? Like a fancier version of UAC's screen dimming? Or maybe we could just choose not to patronize end users so much and use simple, clearly written warnings in these situations. Ones that could be on by default but disabled simply as people progress and become aware of the implications?

See the 3 comments or propose a solution (latest comment the 16 Feb 09 at 17:38) >>

Submit your idea