|
Description
As a seasoned user of the terminal, the issue of an application having an icon embedded into it is something that I didn't even notice until I started converting others to Ubuntu. I propose adding a non-obtrusive section to ELF applications that provides this functionality and can be accessed through GNOME's thumbnail capability. This idea is meant to compliment the icons provided through the package manager and take advantage of the extensibility of the ELF specification.
Many users expect applications that they've downloaded to have recognizable icons, this icon is usually something familiar from visiting the website for the program. A good example of an application that's not already included in the Ubuntu repo is "songbird", which has a large egg right next to the download link and for its Windows icon.
In addition, provided that this technology is adopted by different segments of the development community (GNOME, automake, and developers) then icon handling will no-longer require any action for packagers. GNOME could easily check the ELF binary for an icon, so no configuration file would be necessary for the appropriate icon to appear. By storing a GUID in the binary it would also be possible to theme icons for all system applications (over-riding the icon stored in the binary) by using the GUID as a unique id for matching the application with an icon stored in a theme.
For a technology demo and screenshots visit
http://www.compholio.com/elficon/
(NOTE: Modified 03/27/08 to clarify and better explain impact)
Attachments
Duplicates
Comments
|
rorymccann wrote on the 26 Mar 08 at 12:35
| |
I think we should encourage people to use proper repositories. Then the icons and stuff are included in the package manager.
|
|
Eldmannen wrote on the 26 Mar 08 at 14:51
|
Great idea!
I agree, this is very needed!
|
|
Eldmannen wrote on the 26 Mar 08 at 14:57
|
One of the best ideas, I've seen on Launchpad.
This is definitely something we need.
|
|
jrusinek wrote on the 26 Mar 08 at 16:07
|
Why copying Windows is so much needed for you?
You think Linux is OpenWindows?
Funny...
|
|
Compholio wrote on the 26 Mar 08 at 17:07
|
rorymccann wrote on the 26 Mar 08 at 12:35:
> I think we should encourage people to use proper repositories. Then the icons and stuff are included in the package manager.
The problem with that is that you cannot expect every software package to be distributed using the package manager. Myself I've run into lots of programs that I use daily that are not distributed: Quartus II, LabVIEW, Mathematica, LabVIEW, and Songbird are just a few.
Eldmannen wrote on the 26 Mar 08 at 14:57:
> One of the best ideas, I've seen on Launchpad.
> This is definitely something we need.
Yeah, I think this is something that is really important for new users. I believe that if we develop a reasonable spec for doing this that it could really catch on. This same technique could also be implemented for embedding the "*.glade" file used by libglade applications into the ELF file, removing the necessity for having a folder with additional application resources.
jrusinek wrote on the 26 Mar 08 at 16:07:
> Why copying Windows is so much needed for you?
I haven't seriously used Windows in like 7 years. This issue is a matter of usability for new users, I normally use the terminal for just about everything and don't even notice this for the most part. Ubuntu is a project that tries to make a comfortable operating environment for everyone, not just for people like me and you.
|
|
Eldmannen wrote on the 26 Mar 08 at 19:46
|
jrusinek,
This is not about Windows. This is about user-experience and usability. Don't bash ideas just because there may be something similar in Windows.
|
|
andruk wrote on the 27 Mar 08 at 20:20
|
This is totally needed in Windows, and it would probably become the de facto standard for distributing icons within binaries.
+1
|
|
andruk wrote on the 27 Mar 08 at 21:57
| |
ack, i meant "totally needed in Ubuntu, in order to help new ex-Windows users"
|
|
azrael wrote on the 28 Mar 08 at 08:59
|
This is IMHO a useless idea. There is no prove that binary's having icons help usability. Totally different programs can still have the same icon. People should read file names and look at what program does instead of blindly trusting icons. Mac OS X doesn't have icons for its binary executables. It has icons for packages though.
I'd like to keep all binary files as binarys, with the same "binary file" icon, rather than having to think whether the file is a binary, an icon, or an image.
"The problem with that is that you cannot expect every software package to be distributed using the package manager."
That is the ultimate goal. All software makers should be encouraged to do proper packaging and distributing their packages thru official repositories. Less hassle for them, no need to host repositories. Repositories are the major feature of Linux distributions, that's why we shouldn't give up on them.
Also I'm not sure if changing the ELFs would not break binary compatibility between distributions.
I've voted against.
|
|
Compholio wrote on the 28 Mar 08 at 16:40
|
azrael wrote on the 28 Mar 08 at 08:59:
> This is IMHO a useless idea.
I respectfully disagree, it is useless for me but I know of plenty of people that this would be helpful for. The only way this might make my life easier (as a developer) would be for adding in resources such as *.glade files into a binary so the application doesn't need to look for them.
> There is no prove that binary's having icons help usability. Totally different programs can still have the same icon.
I have run into plenty of people that are confused that all linux programs have the same diamond icon.
> ... I'd like to keep all binary files as binarys, with the same "binary file" icon, rather than having to think whether the file is a binary, an icon, or an image.
Then if this gets implemented you can turn it off, just like you can turn of thumbnailing for pictures and PDFs.
> ... Repositories are the major feature of Linux distributions, that's why we shouldn't give up on them.
I'm not suggesting that we do, this idea is meant to augment existing packaging.
> Also I'm not sure if changing the ELFs would not break binary compatibility between distributions.
It would not, the technique discussed adds a new section to the ELF binary that is not referenced by the application code. This new section is handled kind of like debugging symbols, which you can optionally have in a binary without influencing its execution (you can even use "strip" to remove them from an application after it's made).
|
|
azrael wrote on the 30 Mar 08 at 10:50
|
"Many users expect applications that they've downloaded to have recognizable icons"
These applications obviously don't have packages for Ubuntu. And now you're proposing to enhance Ubuntu's binarys with icons. What's the point of this if those who didn't care to prepare debs for Ubuntu still won't care to make their binarys with icons, since that feature will be only in Ubuntu (at least in the beginning)?
You would have to encourage every distributor of Linux software to change their binarys. If you want to encourage them to anything you should better encourage them to prepare Ubuntu packages.
|
|
Compholio wrote on the 30 Mar 08 at 21:58
|
azrael wrote on the 30 Mar 08 at 10:50:
> ... What's the point of this if those who didn't care to prepare debs for Ubuntu still won't care to make their binarys with icons, since that feature will be only in Ubuntu (at least in the beginning)?
Every idea has to have a beginning somewhere. This kind of thing is something that could conceivably be folded into automake, so a developer would just need to add something like "progname_ICON = 32 iconfile.png". However, this does not to be implemented by developers in order for it to be useful. An icon can be retroactively added to an application, providing a consistent icon throughout the entire UI (something that we do not currently have).
> You would have to encourage every distributor of Linux software to change their binarys.
In order to take advantage of this feature you would want every developer of GUI applications to add this section to their binary. I believe that there is enough benefit to doing this that, given distribution support, developers would do this. However, this is kind of like recycling - every little bit helps even if you don't have everyone doing it.
> If you want to encourage them to anything you should better encourage them to prepare Ubuntu packages.
As much as it would be nice to convince every developer to make an Ubuntu package for their software, this will never happen. There are just way too many distributions to support in making packages, and few developers want to get involved with the war of the package managers. This particular idea avoids the package manager war: if the distribution supports the idea then the app will have a consistent icon no matter what packaging they use, if it does not then the icon must be set by the packager just like things are done now.
|
|
Compholio wrote on the 30 Mar 08 at 22:01
|
Apparently this interface strips greater than and less than symbols, so I'll have to shout. The beginning of the second response SHOULD have read:
In order to take FULL advantage of this feature ...
|
|
jrusinek wrote on the 20 May 08 at 15:00
|
Why do you need icons in elf binaries, if you don't touch them.
You're using .desktop entries, not the binaries from PATH itself.
IMO that's stupid idea and I'm against from its beginning.
|
|
Auzy wrote on the 20 May 08 at 15:37
|
jrusinek How come every time anyone here is against something, they compare it to windows. Thats a weak argument. Especially considering OSX does it too, and it works very well for both them AND windows. If anything, its a +1 for linux.
Linux is about flexibility. By integrating icons into binaries it opens up new opportunities and new ways of doing things. We should always promote ideas that may allow us to do new things.
I solute you comp, and anyone who wants flexibility, and better usability should vote this up. It doesn't hurt to implement it, and there is always a way to override it.
Azrael. I never make debs for my programs, and neither do many other developers I know. Because each package only works on 1 or 2 distro's properly. I'm not going to waste my time doing that. And Distro's differentiate themselves because of packages.
This standard however, could be adopted and be added to any distro, without any con's because its a neutral project, and only affects the top layer of the distro. Whereas, package management is a low level of a distro, so you need a different package for each distro.
This idea compliments my MenuToGo program I just finished coding (and will be launched tomorrow after I finish the release notes). http://sourceforge.net/projects/menutogo/
Combining this with my project, would finally open a new chapter in linux usability.
+1. At the very least, this adds flexibility. And if it wasn't a good way of approaching things, OSX, windows and many other OS's wouldn't be using it. This is obviously a good idea.
And if you aren't a coder and don't understand the benefits, make sure you understand them FULLY before voting. Don't read what me and other people here wrote before coming to a conclusion. Make sure you know why they are useful, shortcomings of the current method, and where this might help. Because I have seen a lot of incorrect arguments made on brainstorm, so make sure u fully understand what you are voting for.
|
|
Auzy wrote on the 20 May 08 at 15:44
|
I'd also like to publically applaud Compholio for taking the initiative and coding his idea.
There are many whingers here I have seen who complain about linux not having their idea, but them being too lazy to code it themselves.
We need more people like it Compholio.
And for people who don't know how to code, they should pick up a C++ book and learn. It actually doesn't take long to learn (or even java which is easier).
The best way to get an idea out there is with a prototype. And since this has one available, people shouldn't particularly be voting it down without at least trying the prototype to get an idea of the general benefits.
Come to melbourne aus Comp, and I wouldn't mind going out to get beers ;) Good job mate. Its good to see us as the brainstorm community getting more and more organised, and the realisation, that nobody can get an idea done better then ourselves (and it takes a load off of Canonical too).
|
|
Compholio wrote on the 5 Jun 08 at 14:13
|
Wow, thanks for the kind words - I definitely wasn't expecting to login and see such positive support. I haven't had a lot of free time lately to work on this, but what I'm currently trying to do is get a hold of James Henstridge (the libglade maintainer). I would like to get libglade/GTK+ to load resources (such as images) straight from the ELF binary, I can currently get libglade to load the icon and the ".glade" file but I cannot see a way to get other resources to work without getting a patch submitted to libglade.
While I would like to get a bit more involved in the community, I fortunately/unfortunately have obligations that will be keeping my occupied in my country for the foreseeable future. However, I am a researcher (Physics) in the US, so it is possible that I might get out for a conference at some point.
|
|
DiegoCG wrote on the 8 Jun 08 at 14:57
|
xattrs already can do all this without touching the binary data. It's already supported by the kernel, and it's much easier to add xattr support to tar, bzip & friends (if it isn't already done). Besides, the main source of ubuntu software are repositories, not external webpages.
|
|
Auzy wrote on the 8 Jun 08 at 15:05
| |
Would you agree though DiegoCG, that we shouldn't assume that they will always be via repository? Wouldn't it be best to do it in a way that always works?
|
|
jdpipe wrote on the 27 Jun 08 at 04:16
|
I vote no. I think that *.desktop fill the necessary gap here of allowing click-the-pretty-icon capability. I think that as a general rule we don't want to encourage these kinds of self-contained quasi-packages; it confuses users and leads us back to a package-manager-that-doesn't-know-what-it's-managing situation that makes application distribution on Windows such a pain.
As for closed source applications on Linux: let them work it out themselves. Not interested! :-)
|
|
Auzy wrote on the 27 Jun 08 at 05:16
|
Yeah JDpipe, it would be a pity if we actually provided flexibility for coders. Lets lock down the operating system so that if users want to run closed source programs, they cant.
That would really help our cause alot. Whilst Ubuntu may be open source, a lot of users are closed minded.
Its good though that a lot of developers and less vocal users aren't so closed minded though..
|
|
Compholio wrote on the 27 Jun 08 at 22:52
|
jdpipe: I am not suggesting that we remove the package manager from the Linux pipeline. I am hoping that taking this tact will actually make things easier for package managers, application developers, and userspace applications to all work together and keep things straight (the point behind including the GUID for the application).
Maybe there's some sort of confusion here (I get this from the comparison to Windows' distribution of applications), but I am not suggesting that configuration files be stored inside the ELF binary. I am only suggesting that actual application resources be stored in the binary. Application resources are things like icons, pictures, and glade project definitions - things that the application relies upon in order to operate, but does not change after distribution or share with other applications.
|
|
Auzy wrote on the 9 Aug 08 at 01:02
|
Actually, if you guys need further proof of why we need this, take a look at what happened after I installed KDE 4.1. Thats absolutely appalling. The last OS I encountered that did rubbish like this was Windows 3.11 (a 20 year old operating system).
Embedding icons is the safest way of doing stuff, because moving stuff around wont break anything. And if you want to go off your custom theming nut, you can always set the system to default to external icons if they exist.
Seriously, this is kind of pathetic, if we want to attract the crowd, icons need to work consistently. I wouldn't DARE show ubuntu to anyone and encourage them to use it, when we still have major issues with problems as basic as icons. What happens when I try to drop 5 of these apps onto the panel, how do I tell them apart?
Get serious for a few minutes please people. We are currently lying to ourselves if we call this OK. In Windows 95 (and greater), and OSX, this problem never arises.
|
|
mdjr wrote on the 10 Aug 08 at 19:09
|
I think a possibility to store a user-readable program name would also be good, just like the VERSION_INFO ressource in Windows executables.
This would enable Gnome to automatically suggest a name for a desktop "starter" icon created. Today you have to type the user-visible name, the command line and select an icon; with a name stored in the executable you just have to type the command line and Gnome would suggest the rest (you have to confirm and are allowed to change this, of course).
>> The last OS I encountered that did rubbish like this was Windows 3.11.
But in Windows 3.x the icons were already stored within the EXE files.
|
|
Auzy wrote on the 10 Aug 08 at 23:27
| |
yeah.. but a lot of programs didn't have icons on Win3.1 (lazy developers).
|
|
Compholio wrote on the 15 Aug 08 at 04:45
|
mdjr:
Actually, my thought was that the entire list of 'program names' and other useful information could be stored in the executable if a standard mechanism was made for storing strings in different languages (this information is currently stored in the ".desktop" files maintained by the packagers). However, this idea is hard enough to push as it is so I have been holding off on putting it into the proposal.
all:
If anyone has any thoughts on promoting this idea I'm all ears, I'm not particularly prominent in the Ubuntu community so it's been difficult to get any significant momentum behind this.
|
Post your comment
|
Bug #207141
Blueprint elficon:
