Propose your solution
Attachments
Duplicates
Comments
|
|
|
I think we should encourage people to use proper repositories. Then the icons and stuff are included in the package manager.
|
|
|
Great idea!
I agree, this is very needed!
|
|
|
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...
|
|
|
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.
|
|
|
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
(Idea reviewer)
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
(Idea reviewer)
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.
|
|
|
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.
|
|
|
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.
|
|
|
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).
|
|
|
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..
|
|
|
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).
|
|
|
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.
|
|
interval
wrote on the 17 Nov 08 at 16:11
|
|
|
|
If properly implemented I suppose its a good thing. I myself don't have a burning need to have my application code and data in one contiguous address space, but I don't care if it is. But the ONE THING no one seems to have addressed is the security aspect. If implemented incorrectly this is a perfect attack vector for virii & trojans. What the hell are you people thinking?
|
|
|
interval:
If you have issues of concern over attack vectors then please take a look at the preliminary spec and bring up any problems you find. I doubt that I've missed any security issues here though, as no "add-in" executable code is run unless the user opts to run the application (which is no different from how things are now). Note that a flaw in rendering PNG or SVG images would also affect this implementation, but if you've got a problem with those libraries then you're already in serious trouble.
|
|
xlinuks
wrote on the 11 Feb 09 at 17:33
|
|
|
I hate lobbyists not having a decent reason try to lobby against by using logical traps like: this is found in windows and thus Linux must not follow/copy it, here's an actual example:
"Why copying Windows is so much needed for you?
You think Linux is OpenWindows?
Funny..."
I for one like very much this idea, it makes the files look better and not depend on external files and paths.
|
|
|
xlinuks:
If you have any thoughts on promoting this idea then I'd appreciate it, as you can see this idea has been around for a while and hasn't gained much traction. The idea itself is not difficult to implement, as evidenced by my example implementation, but I think it's important to get some feedback before establishing something for everyone to standardize on.
|
|
Endolith
wrote on the 30 Mar 09 at 15:06
|
|
|
This topic applies not just to ELF binaries, but to .exe files run through Wine (which already have icons embedded), and other executables, like .py and .jar files (though I don't know of any standard way to embed icons in those).
I'm coming here from Bug 292504, which is about displaying the icons embedded in .exe files. They want to use the Gnome thumbnailer, which I think is a bad idea.
One thing to remember is the Trojan horse factor, where executables in Windows masquerade as jpg files to encourage users to run them. In Linux, this is even worse, since file extensions don't matter. (Your friend's compromised computer sends you an email with OMG_this_chick_is_hot.jpg, which is actually a malicious shell script, for instance.) Allowing it to set its own icon makes for an even more convincing fake. I'm not going to be a moron and say that this is an insurmountable problem, but it should be kept in mind.
Should binaries really be executable directly? I thought the paradigm was to use launcher files (.desktop) to handle the icon and be the thing that the user launches. Maybe there's a completely different paradigm that could be used. Maybe when you view a folder, executable files should be in their own "pane" in the file manager, separate from documents, and with different functionality and appearance. Maybe a launcher should be created automatically when you try to run an executable directly.
If we want users to execute binaries manually, I'm imagining that there will be an "executable" emblem on all of them, to help remind users that they are executable, and then they could optionally set their own unique icon. Originally I imagined a Wine emblem for .exe files, for instance, but maybe it would be better to just have a uniform "executable" emblem that is the same for ELF binaries, .exe files, .py files, etc.
The emblems should be different depending on whether the executable bit for that file is set, and whether the required compatibility layer is installed (if you have a .jar file but Java's not installed, or a .exe file but Wine's not installed, for instance, it would show a "broken" executable emblem). Double-clicking one of these with a broken executable would start an installer for the missing component. Double-clicking one without the executable bit set would explain the dangers of what you're doing and ask if you want to make it executable.
|
|
Endolith
wrote on the 30 Mar 09 at 15:22
|
|
|
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.
Why does it matter? Any program you're distributing is going to be a package of multiple files, whether it's a .deb or a .zip. What's the benefit over including a .desktop launcher and an icon as separate files? Put all the system files in a subdirectory, and leave only the launcher in the zip file's root.
|
|
|
Endolith:
> One thing to remember is the Trojan horse factor, where executables in Windows masquerade as jpg files...
Provided that web applications follow the standard guidelines and do not set the executable bit on the application, then directly downloaded files will not execute when clicked. You will notice that with Firefox or Thunderbird (or other app of your choice) that with any file that you download that you cannot run it until you manually make it executable.
> Should binaries really be executable directly? I thought the paradigm was to use launcher files (.desktop) to handle the icon and be the thing that the user launches.
That's currently the only way to do things, and in my experience it is not sufficient for new GUI users. This method also results in inconsistencies in how icons are displayed depending on how you find the application.
> Maybe a launcher should be created automatically when you try to run an executable directly.
You cannot make a launcher for an executable automatically if you do not have enough information about it. How do you propose to automatically locate the icon or the name of the application in different languages?
> If we want users to execute binaries manually, I'm imagining that there will be an "executable" emblem on all of them, to help remind users that they are executable, and then they could optionally set their own unique icon.
I am not opposed to adding a symbol on top of executable icons, but I do believe that we need to have user-recognizable icons built into the executable.
> Why does it matter? Any program you're distributing is going to be a package of multiple files, whether it's a .deb or a .zip. What's the benefit over including a .desktop launcher and an icon as separate files? Put all the system files in a subdirectory, and leave only the launcher in the zip file's root.
From a developer perspective does this is a pain in the butt, you'll notice that most developers ignore these issues and just leave it up to packagers to do this for them. Distributing an executable that has its major resources included with it makes things much easier for everyone.
|
|
|
From a developer perspective does this is a pain in the butt, you'll notice that most developers ignore these issues and just leave it up to packagers to do this for them. Distributing an executable that has its major resources included with it makes things much easier for everyone.
I really don't see why. It takes a minute or so to create a launcher and connect the icon to it.
|
|
|
Endolith:
> > From a developer perspective does this is a pain in the butt, you'll notice that most developers ignore these issues and just leave it up to packagers to do this for them. Distributing an executable that has its major resources included with it makes things much easier for everyone.
> I really don't see why. It takes a minute or so to create a launcher and connect the icon to it.
Except that you have a couple rather significant issues:
1) Launchers do not support relative icon paths
2) Including the icon separate from the binary requires that the application either find the icon on the filesystem or duplicate the icon in the binary.
For many applications you just have the executable itself, forcing the developer to add a separate file (plus an icon) just to make things look nice is plain silly.
|
|
|
I think even Windows 3.1 had embedded icons in .exes. Just because Windows does it a certain way doesn't mean it's the best way.
What ideally would applications do when you download/install them? Not from a developer perspective, but from a user perspective. Something like:
1. Click on a link
2. It downloads with a progress bar and then installs after making sure you know what you're doing
3. You have an icon in your menu/search tool which you use to start the program
I don't see a reason why a user should be digging around in folders to find executable files and launch them manually
|
|
jyaan
wrote on the 4 Jun 09 at 22:05
|
|
|
This isn't a very good idea, but I don't think it would hurt that much. As mentioned before, any non-trivial project is going to consist of more than a single file. And having the icon in the executable doesn't help much, because we would need to create launchers for them regardless. It's good that we have things installed in a central location.
I think that .deb files with icons could be _great_ though, as long as they have some kind of emblem on them to indicate they are .deb files. Perhaps even an animated icon that swaps back and forth between the default .deb icon and the application icon?
|
|
Tweenk
wrote on the 10 Jun 09 at 12:37
|
|
|
"I have run into plenty of people that are confused that all linux programs have the same diamond icon."
The executable is NOT the program! This is a design issue in Windows. Adding icons to executables will only clone this misconception into Linux. For the novice user, the executable should be an opaque component of the program. There should never be a need to intract with it directly from the file manager.
"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)."
The program name for the launcher is currently stored in that program's gettext file, and the launcher file includes an X-GNOME-Gettext-Domain entry that tells the panel in which gettext domain to look for a localized program name. Embedded translations are wrong because you can't delete the translations you don't need.
"Except that you have a couple rather significant issues:
1) Launchers do not support relative icon paths
2) Including the icon separate from the binary requires that the application either find the icon on the filesystem or duplicate the icon in the binary."
Using relative paths in launchers is WRONG. The proper way to ship an icon is to put it in /usr/share/hicolor/(size dir)/apps, and put only the icon's basename in the Icon field. This way your icon can be themed. As for the application, you need to use gtk_image_new_from_icon_name and GTK will find the proper themed icon for you. Don't know about other toolkits, but they should be similar.
"I think that .deb files with icons could be _great_ though, as long as they have some kind of emblem on them to indicate they are .deb files."
A better idea would be to extend the APT repository to optionally provide an icon list along with the package list. This way, the crude hack of app-install-data could go away since this data could be pulled from the APT repository. Some way of diffing the list should be provided though, so that only the icons that changed / were added need to be re-downloaded.
|
|
Tweenk
wrote on the 10 Jun 09 at 12:49
|
|
|
"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."
GUID is a proprietary implementation of UUID by Microsoft. On top of that, it is inferior to using the application's executable basename, which should be unique anyway.
|
|
|
Hi Compholio,
I promote a project called SFS Technology here:
http://brainstorm.ubuntu.com/idea/20108
Can we implement your great idea also on some squashfs filesystem (SFS Technology executable files) ?
If yes please contact me!
Bye
Vincenzo
|
|
GREENie
wrote on the 18 Jun 09 at 00:22
|
|
|
I am divided on this.
People arguments "everything should be a distro" is silly. I have a personal app I made that has both windows and Linux compiled executable which access same database for my usb.
This way I have something very portable and user friendly. Many other things like portable firefox could have similar thing.
I think icons are very friendly and improve the user experience helping them identify what they are looking for.
I think it is a bad idea on linux because executables have no extension. if an app had a picture of a folder and is a malicious. You can not visually tell if it is a folder or not when browsing. On windows this is acceptable(as long as hide known extensions is off, which it is not by default and I have seen malicious software spread well).
If icons were to be added. There would need to be an overlaid icon to say it is a executable.
|
|
GREENie
wrote on the 18 Jun 09 at 01:04
|
|
|
sorry I meant package not distro.
Someone commented about compatibility between distros.
1. You can make it so it does not effect normal running of an applcation.
2. You can not guarantee Compatibility between distros anyway.
|
|
|
GREENie:
> Someone commented about compatibility between distros.
> 1. You can make it so it does not effect normal running of an applcation.
Correct, this change does not affect the normal execution of an application. You can actually apply icons to existing applications without harming them, thanks to the wonders of the ELF specification. So the only difference would be that some distros would support the icons (or other resources) and other distros would only be able to treat the binaries as normal executables.
> 2. You can not guarantee Compatibility between distros anyway.
Most distros follow the Linux Standard Base, any application that follows these requirements will run on "any" (almost all) distros.
|
|
SirNuke
wrote on the 10 Aug 09 at 02:29
|
|
|
A few thoughts on this:
I've been working on an application that acts as a launcher for a larger applications. It uses libfuse and libzip to mount a virtual filesystem (based off a zip file integrated with the executable), and runs an executable inside the zip (likely either an installer or the application itself).
The basic idea is to provide a fairly bullet proof launcher for a larger application, run from just about any distribution and from anywhere in the system tree, all while only using a single file. This is similar to SFS Technology linked earlier in this thread, but requires nothing additional to be install by the user.
This would never, ever replace deb files or packaging in general. It would, however, be nice for distributing applications that don't interact with the rest of the system, and aren't updated very often (or at all). Examples include a portable version of Firefox, and one of the many small scale SDL based games.
At the moment, the biggest roadbump is the icon (well, that and downloaded executables require a few not necessarily intuitive clicks to actually run, but that's a different topic). .desktop files don't work since it would require at least three files (executable/launcher, .desktop, and the icon), not to mention trying to keep its executable and icon paths correct when all three are moved.
This solution would work very well. Only issue I can see is whether it would interfere with distros that aren't aware of the icons, though that doesn't appear to be the case.
|
|
|
|
For those interested, I've posted an updated version of my the proof of concept implementation (http://www.compholio.com/elficon/). I have also posted binary debian packages of the two components ("libr" and "elfrc", you need both) for both x86-32 and x86-64. If you get a chance, please give it a try and let me know if you have any problems.
|
|
Sloshy
wrote on the 14 Oct 09 at 20:47
|
|
|
In all honesty, this sounds great from a generic "Windows-user", "Double-click-the-exe", "Who-cares-if-it's-secure-I-just-want-it-simple" perspective. Why do I say so? Applications on linux distributions are NOT executable by default and do not have built-in icons for several security reasons.
When you install a package with a package manager, unless it was a CLI app, it will probably have an icon for your menu. An example earlier about how KDE 4.1 .desktop files, by default, were broken in GNOME was a KDE problem. The reason why so many applications use .desktop is because it is more organized (at least from my perspective), easier to modify, and more centralized than the method Windows uses.
I, for one, almost "never" need to run an executable manually by searching through a folder or two to find it, mark it as executable, and open it; if this is the case with most Ubuntu users, then I don't see a reason for things to change. Even still, it's possible for these ELF files to use .desktop files for menus such as when I installed Adobe AIR, which not only installed icons for it, but it installed icons for the other programs I might install.
Another issue is the fact that this would encourage breaking away from package managers. Repositories and package managers are safe, secure, and easy. Why should we use anything else?
Also, on a semi-related note, the *last* thing I want on linux is an equivalent to Windows' TERRIBLE "Autorun". Does it look like I want malware on my machine, people? Things like this are the reasons why Windows is so insecure and why so many people (myself included) use Linux. If we adopt things like this, then not only will standards be broken but Linux would be terribly, terribly insecure.
Simple != secure, and I hope it stays that way.
|
|
Micksa
wrote on the 23 Oct 09 at 14:58
|
|
|
- Just because windows does it does not make it bad.
- Use of embedded icons can work in tandem with systems already in place. The file manager can look for a .desktop file and if none is found then try the executable itself. Thus nobody is *required* to use this method, but it can be *available* to those who wish to.
- There are ways to mitigate security issues that aries with custom icons. Binaries with custom icons can still be marked as binaries, maybe via a label color, a background colour, one of those tiny marker images etc. Also does the standard binary executable icon really stop your average naive user from double-clicking that "greeting-card" trojan?
- There are potential performance improvements. To give you an idea:
mslade@binks:~/t/elfrctest/elfrc$ find /usr/share/icons -type f|wc -l
5326
A lot of these icons are the various formats of icon installed for each application. If these could be folded into the application binary itself, it would save a lot of inodes, slack space, hdd seeks, dpkg/info data, etc
(This is one of my pet peeves - boy that "reading package database" bit sure does take a while)
- This should be done right. I think elfrc as used in the implentation given just adds the icons to the initialised data - so it gets mapped into memory with the rest of the binary. the ELF ABI provides ample opportunity to embed data into the executable file without it getting loaded into memory on execution.
Also the way the icons are stored in the file should probably not make too much use of the ELF data structures - a single ELF section would suffice. The section data would be opaque to ELF and any loaders, linkers etc, and would contain all of the icon data and metadata necessary to select, retrieve and display icons.
Also ".icon" is technically not allowed as a section name, anything beginning with "." is reserved by the ELF ABI.
- There's nothing stopping anyone from using libbfd and a bit of voodoo to create an ELF binary with self-embedded resource data to be used by the binary itself. Why doesn't anybody ever do this? I don't get it. Self extracting executables!
|
|
Sloshy
wrote on the 31 Oct 09 at 23:30
|
|
|
How is "reading the package database" related to this? Do you mean to suggest that the way applications install and such should be independent of any package manager for simplicity reasons? The package manager keeps things organized, simple, and VERY easy to upgrade.
Sorry if my assumption's off, but I still don't see why anyone would need to have this. If the application's installed /the right way/ then there shouldn't be any problems finding the right executable, much less executing it (from the applications menu).
|
|
|
In reply to Micksa:
> ...
> A lot of these icons are the various formats of icon installed for each application. If these could be folded into the application binary itself, it would save a lot of inodes, slack space, hdd seeks, dpkg/info data, etc
If I get some free time again then I'm looking into making this "even better." By allowing you to create a "one canvas" SVG file you wouldn't even need to embed separate icons, the library would strip each icon out of the SVG file and you'd be set to go.
> ...
> This should be done right. I think elfrc as used in the implentation given just adds the icons to the initialised data - so it gets mapped into memory with the rest of the binary. the ELF ABI provides ample opportunity to embed data into the executable file without it getting loaded into memory on execution.
The sections are created with the flags "SEC_HAS_CONTENTS | SEC_DATA | SEC_IN_MEMORY", where "SEC_IN_MEMORY" tells libbfd that it is to build the section data from a pointer - not that the loader should load the section into memory. I do not intend to have the loader automatically load the sections into memory, so if I have made a mistake somewhere then please let me know.
> Also the way the icons are stored in the file should probably not make too much use of the ELF data structures - a single ELF section would suffice. The section data would be opaque to ELF and any loaders, linkers etc, and would contain all of the icon data and metadata necessary to select, retrieve and display icons.
I considered that, but I wanted to make it so that a very minimally application could obtain the icon. I have not added it yet, but a helpful individual contributed some code that is a minimal "grab a section" example. This kind of approach would be nice for a minimal read-only ELF backend that is statically included into a binary (such as a self-extracting executable).
> Also ".icon" is technically not allowed as a section name, anything beginning with "." is reserved by the ELF ABI.
I disagree with your interpretation, the specification states:
---
Section names with a dot (.) prefix are reserved for the system, although applications may use these sections if their existing meanings are satisfactory.
---
I would say that a library for reading and writing resources is "part of the system," so standard things like icons should be included as system sections.
> There's nothing stopping anyone from using libbfd and a bit of voodoo to create an ELF binary with self-embedded resource data to be used by the binary itself. Why doesn't anybody ever do this? I don't get it. Self extracting executables!
I'm not sure, maybe because they prefer self-extracting shell scripts (something I find absolutely abhorrent). It could also be because libbfd is a pain in the butt to use, I know I originally developed this example using libelf and added support for libbfd (now the default backend) when I discovered that libelf had a tendency to corrupt small binaries. You might note that creating a self-extracting executable with libr is really easy.
|
|
Lachu
wrote on the 11 Nov 09 at 09:24
|
|
|
@Solution #2 : Great!
@Solution #1 : Please, according users never will seen ELF binaries. Users can run program only by terminal or by icon, not by ELF executable. If we need to install a program, we downloads .run, .bin or .deb file(never ELF).
|
|
|
In reply to Lachu:
> Please, according users never will seen ELF binaries. Users can run program only by terminal or by icon, not by ELF executable. If we need to install a program, we downloads .run, .bin or .deb file(never ELF).
Open a terminal and run "file ", you will get a response similar to this:
----
: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
----
In other words, ".bin" files are self-extracting ELF executables (these days they're usually made with Icculus' MojoSetup). A ".run" file is a self-extracting shell script (which I personally find horrid, but to each their own). However, in my experience a vast majority of the time I find a binary download for Linux it's a whole collection of files in an archive (.tar.gz or .tar.bz2) where the ELF executable is located at the top level.
I'm likely not a typical user, but have you never used "Open With" in Firefox to find an application like /usr/bin/gedit because the default did not suite you? Wouldn't it be better if Firefox could load the entire list of executable files in the $PATH and apply the appropriate icons and the names of the applications in the local language?
|
|
|
Bah, I hate tag stripping with no warning and no preview. The beginning of that comment should read:
Open a terminal and run "file name_of_bin_file", you will get a response similar to this:
----
name_of_bin_file: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
----
|
|
Lachu
wrote on the 13 Nov 09 at 18:19
|
|
|
@Compholio wrote on the 11 Nov 09 at 18:08 : You have right, but users won't run .run or .bin file with click on them!
We can only run it by terminal emulator/real emulator.
Only exception is Nvidia drivers installer, but it should also be possible to install via console.
|
|
Lachu
wrote on the 5 Dec 09 at 18:26
|
|
|
|
Sunbird should contains desktop file instead a icon.
|
|
jhanely
wrote on the 13 Dec 09 at 07:23
|
|
|
Is there any reason this has to be elf-specific?
I would instead (or maybe in addition) propose that the file manager display a file icon loaded from a specific location within zip files. With no cleverness at all, this would allow for adding display icons to .jar files (and possibly others). With a small bit of cleverness (appending a zip file containing the icon and running zip -A), icons could be added to elf files, shell scripts, and a wide variety of other file types. This is the same trick done to combine a binary and a zip file for self-extracting zip files, for those not familiar with the technique.
As for all the nay-sayers... Well, clearly I'm generally in favor of the idea, and will add my 2cents on the issues.
Security:
Yes, it's an issue. An icon representing how the system will deal with a file should always be overlayed on any icon loaded from the file. This would be a good idea for EVERY icon displayed in the GUI, whether it's a file icon, a .desktop icon, or what. Yes, it would be annoying sometimes, but it would help. No, downloaded files should not be automatically made executable. And under no circumstances should any script or code found in the file be executed automatically by the shell. Good heavens, of course not. But if zips, jpegs and pngs aren't safe to view, we're all screwed anyway.
Package Management:
Yes, it would be nice if every software you'd ever want was listed in Synaptic. It would be nice if every gui app came with a .desktop icon. But I'll give you a use case for doing otherwise:
I make a small application, made up of a single binary (yes, just ONE file, thank you very much), used by a handful of users. The operating systems (and number for each) are:
Windows (10 users)
Mac (1 user)
Gentoo (2 users)
Ubuntu (1 user)
And the one Ubuntu user is probably the least tech-savvy of the lot. I'm one of the Gentoo users myself.
Anyway, I certainly don't want to discourage the use of linux. But I'm also not going to put together a .deb package to send ONE file to ONE user, nor a gentoo ebuild either.
Clearly, the lack of an icon isn't THAT big of a deal. It's just a minor 'sorry, you don't use windows so I can't do it,' which I absolutely hate saying. And heck, I rarely have to. Why should I have to now?
If my reasons aren't compelling to you, that's fine... but I have yet to hear a compelling reason why I shouldn't be allowed to.
|
|
henz103
wrote on the 2 May 11 at 00:03
|
|
|
|
I really like this idea, I miss the "portable static binary with icon executables".
|
|
|
on compiling for 12.04 64bits, I get
libtool: link: gcc -std=gnu99 -m64 -Wl,--export-dynamic -o elfres elfres-gui.o elfres.o -L/usr/lib /usr/lib/x86_64-linux-gnu/libglade-2.0.so -lgtk-x11-2.0 /usr/lib/x86_64-linux-gnu/libxml2.so -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 /usr/lib/x86_64-linux-gnu/libcairo.so -lpango-1.0 /usr/lib/x86_64-linux-gnu/libfreetype.so -lfontconfig -lgobject-2.0 -lglib-2.0 -L/usr/local/lib /usr/lib/libr.so
Setting icon for elfres...
*** buffer overflow detected ***: ./elficon-tmp terminated
======= Backtrace: =========
http://paste.ubuntu.com/1121248/
|
Post your comment
|
Blueprint elficon:
