Community
Participate
Working Groups
Created attachment 262058 [details] example of a .desktop launcher. When you use the Eclipse Installer on Ubuntu, users expect to find Eclipse in the Menu after installation. However, the Installer does not create a .desktop file, so it is not possible to have an icon in the launch bar nor in the menu. The Installer should create an eclipse.desktop file in the eclipse installation folder, so we can use it as a launcher and lock it in the launch bar. Then, to have Eclipse in the menu, it should also create a .desktop file in: ~/.local/share/applications Attachment is an example of a .desktop I did for my Eclipse installation. The .desktop file must be executable.
Is this applicable for all flavor of Linux and for all Window managers variants or just an Ubuntu thing? In any case, this is an enhancement request. Note also that the Eclipse packages don't have such a file, suggesting it's not a universal Linux thing.
This is a standard for Linux, and Bonita BPM, an Eclipse RCP based application is providing a .desktop file. kde: https://techbase.kde.org/Development/Tutorials/Desktop_File gnome: https://developer.gnome.org/integration-guide/stable/desktop-files.html.en the reference example at freedesktop.com: https://specifications.freedesktop.org/desktop-entry-spec/latest/
As a long time Debian/Gnome user I'm always creating this file. Having it auto-generated would definitely be helpful.
Moving all unresolved bugs to version 1.5.0.
This is definitely a good idea.
I tried creating one manually, so I think I'm getting the idea. But what do you do with one of these files? I could move it to the task bar, so that seems definitely nice. But when I run a different Eclipse installation, it seems also associated with that task bar item. Why is that? Unfortunately it seems it must have absolute paths for many of the entries, which wouldn't support roaming. It would be nice if paths could be relative to the *.desktop file. Maybe that's possible?
This is indeed a standard in the Linux (and BSD) world. There is a free destkop specification about it: https://specifications.freedesktop.org/desktop-entry-spec/latest/ and you can see here the needed entries (or taking advantages of others .desktop files installed on the system). https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html means that Exec= isn't forced to be a full path: "The executable program can either be specified with its full path or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH environment variable used by the desktop environment." So, you can leverage the fact that your install would install itself to the user's $PATH (which it should as you are installing binaries).
(In reply to Didier Roche from comment #7) > So, you can leverage the fact that your install would install itself to the > user's $PATH (which it should as you are installing binaries). I am not sure if this is a good fit in this use case. The Eclipse Installer allows many installations of different Eclipse IDE flavors. All them has the name of the launch executable - "eclipse" (eclipse.exe on Windows).
(In reply to Kaloyan Raev from comment #8) > (In reply to Didier Roche from comment #7) > > So, you can leverage the fact that your install would install itself to the > > user's $PATH (which it should as you are installing binaries). > > I am not sure if this is a good fit in this use case. The Eclipse Installer > allows many installations of different Eclipse IDE flavors. All them has the > name of the launch executable - "eclipse" (eclipse.exe on Windows). Yes, I don't want to mess with the user's shell scripts. So fully qualified paths is the way to go, though a notation to specify the location relative to the *.desktop would have seemed more ideal. In any case, it should be pretty trivial to generate this, and of course the user can tailor it as they please after the fact...
*** Bug 479054 has been marked as a duplicate of this bug. ***
I've done some prototyping and am looking for feedback now. In the prototype, I generate the following minimal desktop file: [Desktop Entry] Type=Application Name=Eclipse IDE for Eclipse Committers - Neon Exec=/home/merks/Desktop/sandbox/USER-HOME/committers-neon3/eclipse/eclipse Icon=/home/merks/Desktop/sandbox/USER-HOME/committers-neon3/eclipse/icon.xpm Terminal=false I generate this to /home/merks/Desktop/sandbox/USER-HOME/committers-neon3/eclipse/eclipse.desktop and I make sure to set the execute permission. It seems to work well. Are important/useful things missing? I've not generated this to ~/.local/share/applications. I'm not sure I should. I could, but maybe not everyone wants that. There's also the problem of ensuring unique file names in that folder. I imagine one could just create a symbolic link there, and then the file name wouldn't matter, as long as it's unique. So is it good enough that it's generated in the installation so the user can copy or symlink it if that's what they really want? Opinions?
(In reply to Ed Merks from comment #11) > Name=Eclipse IDE for Eclipse Committers - Neon I would avoid including any version (like Neon) in the Name. When the user updates to Oxygene then the .desktop file won't be updated. > Are important/useful things missing? We can also have the following two: Comment=Some useful comment Categories=Development;IDE;
Comments below. (In reply to Kaloyan Raev from comment #12) > (In reply to Ed Merks from comment #11) > > Name=Eclipse IDE for Eclipse Committers - Neon > > I would avoid including any version (like Neon) in the Name. When the user > updates to Oxygene then the .desktop file won't be updated. > Maybe I'm special, but I install lots of versions of the same product. It would seems generally annoying if I can't tell them apart. In any case, this highlights a fundamental concern. Given 10 people, will there be 10 different opinion on what the name should be? > > Are important/useful things missing? > > We can also have the following two: > > Comment=Some useful comment What useful comment could I possibly generate? The description in the branding information, e.g., Package suited for development of Eclipse itself at Eclipse.org; based on the Eclipse Platform adding PDE, Git, Marketplace Client, source code and developer documentation.<br/> <br/> Click <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Platform">here</a> to file a bug against Eclipse Platform.<br/> Click <a href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit">here</a> to file a bug against Eclipse Git team provider. But we'd want to prune that down like we do on the simple page. Is that useful? > Categories=Development;IDE; Why those? Are these relatively standard terms? Note that the installer in general can install any product definition, i.e., the installer can even install the installer product itself. So we'd probably want additional branding annotations to control this; though it's only useful for Linux. What about the issue of the link/copy in/to the applications folder? Should the user just do that manually?
(In reply to Ed Merks from comment #13) > (In reply to Kaloyan Raev from comment #12) > > (In reply to Ed Merks from comment #11) > > > Name=Eclipse IDE for Eclipse Committers - Neon > > > > I would avoid including any version (like Neon) in the Name. When the user > > updates to Oxygene then the .desktop file won't be updated. > > > > Maybe I'm special, but I install lots of versions of the same product. It > would seems generally annoying if I can't tell them apart. In any case, this > highlights a fundamental concern. Given 10 people, will there be 10 > different opinion on what the name should be? Yes, you are special :) I don't recognize you as an ordinary Eclipse user. > > > Are important/useful things missing? > > > > We can also have the following two: > > > > Comment=Some useful comment > > What useful comment could I possibly generate? > > The description in the branding information, e.g., > Package suited for development of Eclipse itself at Eclipse.org; based on > the Eclipse Platform adding PDE, Git, Marketplace Client, source code and > developer documentation.<br/> > <br/> > Click <a > href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Platform">here</a> > to file a bug against Eclipse Platform.<br/> > Click <a > href="https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit">here</a> to > file a bug against Eclipse Git team provider. > > But we'd want to prune that down like we do on the simple page. Is that > useful? Should be shorter. I think just "Package suited for development of Eclipse itself at Eclipse.org" is enough. > > Categories=Development;IDE; > > Why those? Are these relatively standard terms? Take a look here: https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html#category-registry > What about the issue of the link/copy in/to the applications folder? Should > the user just do that manually? I don't have a strong opinion here. I don't see an issue to generate the file directly under ~/.local/share/applications.
+1 for Categories=Development;IDE; This way, when someone link the .desktop in ~/.local/share/applications, Eclipse will be displayed in the right menu subgroup. Very useful. For the comment, let's keep something very short. +1 also for the detailed name. When you install many Eclipse, it is better to have some details, to be sure which one you start.
For several days now I've been playing with these .desktop files and other things such as .setup file association registration because I find the promise interesting. Unfortunately I discover some very nasty and sometimes unpredictable behaviors. Here are some of my observations and I hope that the linux experts can help... We can't ship a fixed .desktop file because we can't anticipate where on their disk users will unpack our archive. So I experimented with automatically generating a .desktop file on startup, if needed. "If needed" means that the generated .desktop file adds a special command line option (-desktop=...), so that the installer application can tell whether it has been started via that .desktop file, or not. If not, the installer generates the .desktop file (very early while the splash screen is still displayed), launches the new .desktop file (via gtk-launch, which in turn launches the installer) and exits. This way I was hoping that users can lock the installer icon to their launcher/launchbar and that always our generated .desktop file would be locked to it (instead of the native installer application itself). Unfortunately it appears that, when they actually lock that process/icon to their launchbar, "something" generates a new .desktop file "swt.desktop" and creates a new icon "swt.png", which will become the locked "things". I suspect that is because Eclipse's native launcher replaces its own process by a newly forked Java process, which then has no relation anymore to the original .desktop file. I couldn't figure out, why and when this SWT-related set of files is genrated and by whom. I suspect that it is SWT itself because nothing in the respective command line (see Exec=...) seems to give any clues on SWT: [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application Name=Eclipse Installer Icon=swt.png Path=/home/stepper/oomph/git/org.eclipse.oomph/products/org.eclipse.oomph.setup.installer.product/target/products/org.eclipse.oomph.setup.installer.product/linux/gtk/x86_64 Exec=/home/stepper/java/bin/java -Xms256M -Xmx1024M -jar /home/stepper/oomph/git/org.eclipse.oomph/products/org.eclipse.oomph.setup.installer.product/target/products/org.eclipse.oomph.setup.installer.product/linux/gtk/x86_64//plugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar -os linux -ws gtk -arch x86_64 -showsplash -launcher /home/stepper/oomph/git/org.eclipse.oomph/products/org.eclipse.oomph.setup.installer.product/target/products/org.eclipse.oomph.setup.installer.product/linux/gtk/x86_64/eclipse-inst -name Eclipse Installer --launcher.library /home/stepper/oomph/git/org.eclipse.oomph/products/org.eclipse.oomph.setup.installer.product/target/products/org.eclipse.oomph.setup.installer.product/linux/gtk/x86_64//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.300.v20150602-1417/eclipse_1612.so -startup /home/stepper/oomph/git/org.eclipse.oomph/products/org.eclipse.oomph.setup.installer.product/target/products/org.eclipse.oomph.setup.installer.product/linux/gtk/x86_64//plugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar --launcher.appendVmargs -exitdata 1200010 -data @noDefault -desktop=EclipseInstaller -vm /home/stepper/java/bin/java -vmargs -Xms256M -Xmx1024M -jar /home/stepper/oomph/git/org.eclipse.oomph/products/org.eclipse.oomph.setup.installer.product/target/products/org.eclipse.oomph.setup.installer.product/linux/gtk/x86_64//plugins/org.eclipse.equinox.launcher_1.3.100.v20150511-1540.jar StartupNotify=false StartupWMClass=SWT OnlyShowIn=Unity; X-UnityGenerated=true The Exec=... property also seems to contain wrong/redundant values, such as -Xms, -Xmx, and -jar. What bugs me most is that the exact name of the .desktop file is ALWAYS "swt.desktop" and it is NOT overwritten, if a totally different SWT program is started and locked to the launchbar. This different program will just pick up the one existing swt.desktop file and use totally wrong properties!!! To me it seems that this mechanism is totally broken ;-(
Actually, I created my .desktop file after the installation, and it's working great (see attachments for example) At Bonitasoft, we used to do just a simple .desktop file like that , for our RCP application (Bonita BPM Studio). Do you want me to ask the dev who did this? The only thing you need is to set the right path in the .desktop with a script knowing where the application is installed. And I have no issue like what you describe.
Out of desperation I tried one more approach and that works a little bit better. Still investigating...
I am on Linux Mint Mate 18.2 64. I support that The Installer should create an eclipse.desktop. IMO Ecclipse should install like any other app, creating its icon in the Menu and - which is even more important for me - creating its link in the Open With context menu! Besides, it should create the same type of entree when I edit my files in /var/www/html/ as a superuser.
(In reply to Ed Merks from comment #6) > I tried creating one manually, so I think I'm getting the idea. But what do > you do with one of these files? I could move it to the task bar, so that > seems definitely nice. But when I run a different Eclipse installation, it > seems also associated with that task bar item. Why is that? > > Unfortunately it seems it must have absolute paths for many of the entries, > which wouldn't support roaming. It would be nice if paths could be relative > to the *.desktop file. Maybe that's possible? The many instances of eclipse associated to the same icon is caused by the StartupWMClass property. Currently all eclipse versions is using the same value: "Eclipse". I have used the tool MenuLibre to identify that property: https://www.youtube.com/watch?v=EAycFBCA6EE
see Bug 500571
Confirmed. Not having a launcher icon (.desktop entry) for a GUI app like Eclipse in the year 2019 is a bug. At the end of the installation process for each Eclipse component a dialog should ask the user if they want a .desktop entry to be added to the menu. Version: 2018-12 (4.10.0) Build id: 20181214-0600
(In reply to Pico R from comment #22) > Confirmed. Not having a launcher icon (.desktop entry) for a GUI app like > Eclipse in the year 2019 is a bug. > > At the end of the installation process for each Eclipse component a dialog > should ask the user if they want a .desktop entry to be added to the menu. > > > Version: 2018-12 (4.10.0) > Build id: 20181214-0600 Here is a sample ~/.local/share/applications/eclipse-js.desktop [Desktop Entry] Version=1.0 Type=Application Name=Eclipse JavaScript Icon=/home/user/eclipse/javascript-2018-12/eclipse/icon.xpm Exec=/home/user/eclipse/javascript-2018-12/eclipse/eclipse Comment=Eclipse JavaScript IDE Categories=Development;IDE; Terminal=false StartupWMClass=eclipse-js
(In reply to Pico R from comment #23) > StartupWMClass=eclipse-js Note that this doesn't work as you are expecting. mainly if you have multiple instances running at same time. if you have ubuntu, start your eclipse instance. Then type Alt-F2, then in the "enter command dialog" type: lg once a window is opened, click on Windows tab, where you can see which WMClass your apps were registered with... I don't think it is eclipse-js
*** Bug 563812 has been marked as a duplicate of this bug. ***
@Ed thanks for taking care here, I'm just wondering: Would it be an option to have a simple Dialog at the end, filled with some defaults the user can edit? Things I would recommend: - Name (filled by default with the name of the installed product) - location (filled by default with ~/.local/share/applications) - icon (filled by default with the xpm file in the root of the installation folder) - comment (don't know if there is description for each product) In the end I think a "not everyone is satisfied" solution would be better than nothing.
(In reply to Christoph Laeubrich from comment #26) > @Ed thanks for taking care here, I'm just wondering: > Would it be an option to have a simple Dialog at the end, filled with some > defaults the user can edit? > I suppose that's one way. Or perhaps open an editor on a default that's already been created so the user can further edit it. > Things I would recommend: > - Name (filled by default with the name of the installed product) > - location (filled by default with ~/.local/share/applications) > - icon (filled by default with the xpm file in the root of the installation > folder) > - comment (don't know if there is description for each product) > Yes, the products do generally have a description. > In the end I think a "not everyone is satisfied" solution would be better > than nothing. Yes, I can imagine I'd find the absence annoying/sad if I actually used Linux day-to-day...
(In reply to Ed Merks from comment #27) > Yes, I can imagine I'd find the absence annoying/sad if I actually used > Linux day-to-day... How does it works under windows? Maybe the approach could be adapted?
(In reply to Christoph Laeubrich from comment #28) > (In reply to Ed Merks from comment #27) > > Yes, I can imagine I'd find the absence annoying/sad if I actually used > > Linux day-to-day... > > How does it works under windows? Maybe the approach could be adapted? It's also kind of horrible, implemented by calls to this method: org.eclipse.oomph.setup.internal.installer.KeepInstallerUtil.createShortCut(String, String, String, String)
Thanks for the hint I used the Oompf-Installer and choose "Eclipse for Contributors" and then Oompf to start an installer from the IDE (how many turtle can you stack?) but the 'org.eclipse.oomph.setup.installer.product' complains about missing dependencies, do I need to activate a special target or something?
Try using the configuration: https://www.eclipse.org/setups/installer/?url=http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/configurations/OomphConfiguration.setup&show=true I'm not sure which target platform defaults kick in without that...
I used that to install another eclipse setup, but the product still complains, e.g. org.eclipse.platform: Missing constraint Require Bundle org.eclipse.ui.intro [3.2.0,4) if I proceed I get various exceptions in the log an application does not start.
(In reply to Christoph Laeubrich from comment #32) > I used that to install another eclipse setup, but the product still > complains, e.g. org.eclipse.platform: Missing constraint Require Bundle > org.eclipse.ui.intro [3.2.0,4) if I proceed I get various exceptions in the > log an application does not start. I'm not sure I follow exactly what you are seeing. If the installer fails to resolve the requirements, it can't proceed. So this is something happening in the workspace, perhaps resolving the target platform? Perhaps a screen capture or log contents will make it more clear to me what exactly you are doing.
Created attachment 283118 [details] Validation Screen 1) I run the installer with the provided -> everything works fine and I can start the IDE 2) Now I'm in the IDE and I see all projects are compile without errors 3) I open the file "Installer.product" and hit the "Validate" button -> the validator complains about multiple missing constrains 4) I choose to continue anyways --> The product launch is aborted with errors
What I then tried is opening org.eclipse.oomph.tp.target and "set as active target platform" but problem persist as before.
What happens if you just do Help -> Perform Setup Tasks... Note that the wizard runs in the background and there is an animated button in the status line that can be used to reopen it. This should just automatically resolve the target platform. The Modular Target should be the active target platform in the PDE preferences. No not use the *.target file. It's generated and is used only for the Tycho build.
Created attachment 283121 [details] Download Failure Message Thanks for the hint, I performed the setup task and got the error about download-failure. I then proceed with "yes" and verified that all tasks are completed via the 'Progress-Part' but the error(s) are still there.
Yes, I keep getting that message too. I think something is messed up in that update site. :-( But regardless of whether I hit yes or no, it proceeds... For you something fails after?
Yeah.. I just get the "Failed to start the Application do you want to view the logfile" and that log is full of unresolved error messages :-\
(In reply to Christoph Laeubrich from comment #39) > Yeah.. I just get the "Failed to start the Application do you want to view > the logfile" and that log is full of unresolved error messages :-\ I'm really confused though. Your comments suggested you are in an IDE and are resolving a target platform, but who knows, you could be in the installer. So what application are you trying to start? Running the setup tasks in an IDE does not try to start any application, so that doesn't jibe. Do you have an IDE or not? Showing a picture of a dialog box is not all that helpful in terms of context...
If I look at at the contents of that repository that fails, it looks a little odd: https://download.eclipse.org/justj/?file=releases/2020-06/202005081000 The timestamp of content.xml.xz is older than all the others. That's kind of inexplicable...
Hi Ed, sorry for confusion and thanks for the patience. What I want to archive: Having an Eclipse-IDE containing the sources of Oompf so I can Debug/Develop Code to add desktop launcher for Linux. What I did: - downloaded the Eclipse-Installer from Eclipse.org page - Switched to Advanced Mode, selected "Eclipse for Contributors" and on the next page choose the Project "Oompf" (as an alternative I have used the .setup file you supplied but this seems to be identical) - After installation I head over to the directory and started the generated Eclipse, opened the file "Installer.product" - I hit the green "Run as RCP Application" Button and get the validation error Dialog shown in the Screenshot - I choose proceed but this only leads to another dialog that tells the product can't be started and the log is full of errors I hope its clear until this point? As the validation screen suggest that something is missing I tried to load the target-file from the build, that dosen't help and as you suggested I re-run the setup task but that dind't solve the issue either. Thats it, let me know If you need additional information.
(In reply to Christoph Laeubrich from comment #42) > Hi Ed, sorry for confusion and thanks for the patience. > > What I want to archive: Having an Eclipse-IDE containing the sources of > Oompf so I can Debug/Develop Code to add desktop launcher for Linux. > > What I did: > - downloaded the Eclipse-Installer from Eclipse.org page > - Switched to Advanced Mode, selected "Eclipse for Contributors" and on the > next page choose the Project "Oompf" (as an alternative I have used the > .setup file you supplied but this seems to be identical) That should be okay, but the Configuration is intended to make these choices for you and to choose the target platform version... > - After installation I head over to the directory and started the generated > Eclipse, opened the file "Installer.product" There is no need to work with this file. > - I hit the green "Run as RCP Application" Button and get the validation > error Dialog shown in the Screenshot You should look in the debug configurations and use the Setup (Installer Dialog) to launch the application. > - I choose proceed but this only leads to another dialog that tells the > product can't be started and the log is full of errors > > I hope its clear until this point? > Yes, now it's clear. But don't do that. :-P Just debug launch the installer application (using the provided launcher, which you may need to modify if you are not on Windows). > As the validation screen suggest that something is missing I tried to load > the target-file from the build, that dosen't help and as you suggested I > re-run the setup task but that dind't solve the issue either. > > Thats it, let me know If you need additional information. Forget about the *.product. I don't know what PDE all wants to do to launch such a thing. But it's not necessary. Everything to run the installer application is already compiled and available in the workspace (and there is a launcher already).
Thanks Ed I finally found that, no idea why I missed the entries there... Maybe it would be good to have these already marked as favorites via the setup-file so the are more prominent to the new user. One thing I noticed now: It seems the create shortcut is only available in "Simple Mode" via SimpleVariablePage and not in advanced mode is this correct/intentional? In Advanced mode it seems only be used in KeepInstaller to install the Installer itself?
(In reply to Christoph Laeubrich from comment #44) > Thanks Ed I finally found that, no idea why I missed the entries there... > Maybe it would be good to have these already marked as favorites via the > setup-file so the are more prominent to the new user. > One thing I noticed now: > It seems the create shortcut is only available in "Simple Mode" via > SimpleVariablePage and not in advanced mode is this correct/intentional? > > In Advanced mode it seems only be used in KeepInstaller to install the > Installer itself? Yes, we could add them as favorites; I've done that for other setups... Yes, it's somewhat intentional that advanced more doesn't create shortcuts because these generally involve project setups so the IDE installation and the workspace it uses are rather tightly coupled... But in principle there is no reason it shouldn't work there too...
New Gerrit change created: https://git.eclipse.org/r/164305
@Ed I have started with a supporting refactoring by extracting the task of shortcut creation into a dedicated interface with the powershell being the only implementation if the OS is windows. It would be good if you (or someone else) can review/test this and if it is fine and merged to master I'll try to add an implementation for Linux.
Gerrit change https://git.eclipse.org/r/164305 was merged to [master]. Commit: http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=930a7845dc971eb9927db34acb6d03cca80133f5
I'll leave this open pending your contribution for the Linux-specific support. Thanks for the contribution! And sorry it took so long to process.
No problem I hope I can add support soon.
@Ed it seems I need a hint again, I have added an empty Linux implementation, and now the "create shortcut" appears in the simple mode. But when I hit install I get the following error: > ERROR: org.eclipse.equinox.p2.metadata.repository code=1000 > No repository found at file:/<git repo path>/git/org.eclipse.oomph/sites/org.eclipse.oomph.site/target/repository/. (I started the "Setup Installer Dialog Online)
Both the installer launchers include redirections for the update site to use the locally built site. -Doomph.update.url=${file_uri:${resource_loc:/org.eclipse.oomph.site}}/target/repository/ This is typically important so that one can test the local changes in the deployed installation. In this case that, all your changes affect only the installer itself so that's not really necessary. Just remove the above -D option to use the default remote update site.
New Gerrit change created: https://git.eclipse.org/r/c/oomph/org.eclipse.oomph/+/165847
I have now added support for Shortcut+Menu in simple mode, at least under Debian with Gnome 3 it works as expected. In advanced mode currently there is no way to create a shortcut but I think especially there it would be useful, should I open a new ticket for this?
Gerrit change https://git.eclipse.org/r/c/oomph/org.eclipse.oomph/+/165847 was merged to [master]. Commit: http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=a0bf842d3539f2a34516ccd2b1b257950875db37
(In reply to Christoph Laeubrich from comment #54) > I have now added support for Shortcut+Menu in simple mode, at least under > Debian with Gnome 3 it works as expected. > > In advanced mode currently there is no way to create a shortcut but I think > especially there it would be useful, should I open a new ticket for this? Yes, please use a new bugzilla for support in simple mode. This seems a bit trickier because it's more likely to result in "duplicates" if just the product/version name is used... Otherwise I think this Bugzilla is done, though I have not personally tested that it works on my virtual box's Linux variant...
As there are myriads of linux-variants I think one can't test all for sure, but hopefully people will come up with a report if it does not work for them :-)
(In reply to Christoph Laeubrich from comment #57) > As there are myriads of linux-variants I think one can't test all for sure, > but hopefully people will come up with a report if it does not work for them > :-) Thanks so much for getting involved and contributing!!
