394
votes
|
|
418
5
24
|
|
|
|
|
64
votes
|
|
109
27
45
|
|
|
|
|
|
Propose your solution
Attachments
No attachments.
Duplicates
Comments
|
Auzy
wrote on the 24 May 10 at 11:35
|
|
|
|
I recall suggesting this in the past, and I STRONGLY agree. Windows already does this, and the number of formats and devices which Linux can potentially support by extensive googling is totally irrelevant if it takes more work to get them going than it does to boot into windows.
|
|
lvxferre
wrote on the 24 May 10 at 13:01
|
|
|
|
I strongly agree with this idea too. Not only for newbies - it makes the things easier to EVERYONE, and I think it's pretty viable.
|
|
|
|
Not an extension based system for this, please
|
|
ingalls
wrote on the 25 May 10 at 20:38
|
|
|
This would be amazing!
It would save me alot of time. Instead of coming to ask what app to install, ubuntu could suggest one for them!
|
|
Auzy
wrote on the 26 May 10 at 05:50
|
|
|
|
Bruno, you need to use a hybrid of extensions and data for it to work.. Remember, python files are seen as text files (which is why you need to use both)
|
|
|
|
I understand. I think a right click menu option could be a better solution.
|
|
Shnatsel
wrote on the 27 May 10 at 19:59
|
|
|
|
Gnome-app-install had both of the proposed features. Rest in peace, app, we still love you...
|
|
|
While this isn't a bad idea in principle, the problem comes when deciding what application(s) to suggest for each file type.
In the Ubuntu repositories, there are several, if not dozens of different apps for each possible file type. How do we decide what to recommend? For example, what if a user tries to open a ".rar" archive? Should we recommend the Free Software package, or the non-free one? The non-free one is more likely to work, but isn't something we should be promoting.
All I see coming out of this idea is a war over various preferences regarding the suggestions. Even if multiple possible programs could be suggested, people will almost certainly install the first one, and so again there will be disagreement as to what order the suggestions should be.
Moreover, this could cause issues with downstream distros that are based on Ubuntu, which might have different ideas as to what packages to recommend or condemn.
|
|
|
@TwistedLincoln
"All I see coming out of this idea is a war"
That's why I like Ubuntu not being a democracy. Let's say popularity, let's say an "Order by" selector, let's say what Mark Shuttleworth dictates or someone at the UX group at Canonical. The world will be then a better place than it is now, with users going back to Windows because they are not able to open their rar files.
Indeed I think the biggest threat for free software is its own community, which in turn is the reason why it will prevail over proprietary software. We have to think in the free software space, which is far more versatile than the proprietary software space is.
Coming back to Earth, no one stops you from proposing a solution for each pre-selection/suggestion/recommendation/promotion/condemnation criteria you can imagine.
|
|
|
|
I don't follow.. It's the same scenario in Windows at fist you cant unpack RAR so you'll need ex winrar, who tells them that there... Nope, little bit of common sense thats what needed. Google is your friend, if you cant figure out how to install rar-plugin then take a new app like xarchiver.
|
|
|
Thanks you very much.
I understand. I think a right click menu option could be a better solution.
|
|
|
@pont.andersson
> I don't follow.. It's the same scenario in Windows at fist you cant unpack RAR so you'll need ex winrar, who tells them that there... Nope, little bit of common sense thats what needed. Google is your friend, if you cant figure out how to install rar-plugin then take a new app like xarchiver.
You won't be there to explain them Windows is not better than Ubuntu and that Google has all the answers; they'll simply find a neighbor to re-install windows for them; with a variety of extras, including rar managers. And then Ubuntu just lost another user because of pretending "the user just have to know that".
If you want Ubuntu to copy Windows in its limitations that's a respectable opinion, but is not mine's.
|
|
Auzy
wrote on the 31 May 10 at 05:31
|
|
|
Actually, you both miss the point.. Windows already has this built in. The database isn't that great though.
|
|
|
|
"Extensions" aren't always present for Unix and Linux filenames, and aren't as critical a piece of metadata when they are present. However, there is the classic command line tool 'file', which is more sophisticated. Perhaps a solution involving both 'file' and filename "extensions," in the background, would be an effective approach.
|
|
wenex
wrote on the 31 May 10 at 17:48
|
|
|
a file type explanation in star dict style or so?
i like the right click option
it helps learning by doing
|
|
Auzy
wrote on the 31 May 10 at 21:40
|
|
|
|
I agree bgvaugh.. it needs to be a hybrid to be effective.
|
|
|
@Auzy
>Remember, python files are seen as text files (which is why you need to use both)
Not entirely true. If the script begins with #!/usr/bin/python then the results are:
----------
user@host:~$ file lol.py
lol.py: python script text executable
----------
It seems to me that the simplest solution is most often the best solution. Using a hybrid approach adds unnecessary levels of complexity, especially when you consider that 'file' definitions can be easily customized to account for all of the most common file types. The compiled file containing the definitions is called magic. Check it out:
----------
user@host:~$ less /usr/share/misc/magic
----------
Now, how many more times can we use the word 'file' in a paragraph before it becomes totally confusing? :-D
|
|
Auzy
wrote on the 1 Jun 10 at 10:57
|
|
|
The python standard doesn't require that #!/usr/bin/python is there famicommie..
So you can't rely on it.
|
|
Auzy
wrote on the 1 Jun 10 at 11:27
|
|
|
And the fact that Linux distro's insists that every company follows their standard which only works on Linux OS's to make files work, is a BAD thing..
|
|
|
Fair enough. AFAIK, the python standard doesn't require an extension, either. In the case where the script author neither uses the shabang nor the conventional extension, how do you suggest python files be identified?
Let me try a different approach. Besides scripts (which really are text files, anyways), what commonly used file types are only identifiable by extension? If 24/25 file types are correctly identified by the file utility, then the hybrid approach feels pretty inelegant. Do we want to expect the system to check the extension every time certain file types are accessed?
|
|
Auzy
wrote on the 2 Jun 10 at 06:58
|
|
|
It doesn't require an extension, but I doubt I have ever seen a python file named anything differently to .py
I also have an application known as MenuToGo, where my menu files are XML, and are detected as txt files. Yes you could add a way to make them work anywhere, but frankly, nobody else is going to name their files menutogo.
Also, as mentioned, .py is ONLY a linux thing. Windows users WONT add #!/blahpython because they don't need it.
Furthermore, give me one good reason why it's good to hardcode in #!/bin/env.. What if we want to change /bin/env's path in the future? Break all scripts working?
That's why you use a hybrid
|
|
Auzy
wrote on the 2 Jun 10 at 16:37
|
|
|
|
Egh.. I mean #! is only a linux thing.. Not .py.. That's universal
|
|
Liso22
wrote on the 4 Jun 10 at 18:42
|
|
|
I hate the problem, and love the solution. Very simple and logic, though I find the rationale and solution a bit overly complicated.
If I got it right basically, all apps on the soft center would have to specify which extensions work with.
Then clicking a file which one can't open would prompt the possible applications the user needs.
|
|
Liso22
wrote on the 4 Jun 10 at 18:44
|
|
|
I hate the problem, and love the solution. Very simple and logic, though I find the rationale and solution a bit overly complicated.
If I got it right basically, all apps on the soft center would have to specify which extensions work with.
Then clicking a file which one can't open would prompt the possible applications the user needs.
On a sidenote: It would be nice to access the function even if you already have a program to open the file, by clicking open with other application you would somehow have the option to download compatible apps.
|
|
|
What is wrong with file extensions?
I like the idea of being able to tell what type of data a file contains from its extension.
I maintain a list of standard file extensions here, so I see no problem in implementing solution #1.
There is a weird problem with the way that man pages are implemented, that makes it difficult to know that a file containing man page data is a manual page:
foo.1.gz
I would like to see the convention changed here to make it clear that the file is a man page, eg:
foo.1.man.gz
(In the case of a compressed file, the last extension indicates the decompression type, and the last but one extension indicates the content type of the uncompressed data. We may need to consider this on implementation.)
With regards to application preferences, we could always provide a configuration file that switches preference order for one application over another.
|
Post your comment
|
