Am Montag, 5. September 2011, 10:17:34 schrieb Carsten Haitzler: > On Sun, 4 Sep 2011 12:26:04 +0200 Alex Baer <comet.fri...@gmx.net> said: [...] > > > > 1. Menu configuration > > There's a choice between "Enlightenment" and "KMenuEdit". What's the use > > of the latter? The effect is, that the applications menu is completely > > empty. Is that the correct/intended behaviour? > > chances u have a custom .menu file (called KMenuEdit.menu) in > /etc/xdg/menus OR ~/.local/etc/xdg/menus and that is why e offers it as a > menu option. that file was probably created by "kmenuedit" at some point > when you used it and it happens to be useless/empty. enlightenment > installs its own .menu file so that it will work on those minimalist > systsems that dont already have a set up and working "standard" xdg menu > system in /etx/xdg/menus
Makes sense. It's just not obvious for an e noob like me. Maybe a tooltip or something would be helpful here. Just for curiosity: If Gnome was installed, would there be an entry for the Gnome menu editor, too? > > > 2. Menu language > > Selecting Enlightenment for a menu, alls the applications in my system > > are included in the menu, and in the correct place. Even names and > > labels are translated correctly, just like in KDE. > > However, one level above in the menu hierarchy are the categories, to > > which applications are associated, and these are, unfortunately, always > > shown in English, regardless of any language setting or locale. E. g., > > in KDE I see "Büro" as a translation for "Office", but in E17 it's still > > "Office". Yet another level up, in the root menu, translation works, > > again. Only for the category it doesn't work. Can I change this with a > > setting or is this a bug? > > do the .directory files referred to contain translations? eg > Utility.directory? these normally are provided by your OS and they specify > label, icon and translations. i know ubuntu moved all translations out of > .desktop (and .directory) files into some other translation databases. i > don't actually know how this standard was modified at this stage, but e > doesn't support this separated translation setup, so if the .desktop and > .directory files don't have translations Yes, the .directory files are in /usr/share/desktop-directories, and they do contain translations Example: kde-utilities.directory [Desktop Entry] Encoding=UTF-8 Type=Directory Name=Utilities [...] Name[de]=Dienstprogramme [...] Comment=Utilities [...] Comment[de]=Dienstprogramme So there are translations for the various categories in the .directory files, but they aren't picked up by e, as it seems. Application names and labels in the sub-menu for each category, however, are translated correctly, e. g. "KCalc (Wissenschaftlicher Taschenrechner)". The .desktop files in /usr/share/kde4 also have translations included. BTW, e has no category "Utilities", here. Under "Anwendungen" (Applications) I see these: Accessories Development Games Graphics Internet Multimedia Office Other System Universal Access They should translate to something like this: Zubehör Entwicklung Spiele Grafik Internet Multimedia Büroprogramme Sonstige System For Universal Access I don't have a good translation, at hand, and KDE might have a better translation for Accessories than Zubehör. (The one big advantage of KDE is there excellent and well thought out approach to internationalisation and localisation, but that's a different story). > > > 3. Window opening and closing in the config dialog > > When I change setttings I click on options or categories and a dialog > > opens. to close the window I have to explicitly click on its "Close" (or > > "Schließen") button. In other DEs I can click a second time on the > > options that opened the window, to close it. I find this comfortable, as > > I don't have to move the mouse to an (accidentally) opened window. > > Are there any plans to add this comfortable functionality to E17? I can > > only speak for myself, but I'd appreciate it. > > this is settled now i think :) in fact in the gnome control center.. it > does what e does - it shows/raises the same window... so what you REALLY > want to say is " i just came from kde and i want kde's behavior thanks!". Well, not quite. ;) I just have had several years to get used to another paradigm, and now have to re-learn, what I believed to know. And as you will know, re-learning is harder than learning something completely new. But I am too young to stop learning! :) > e's behavior isn't configurable here and does at least what we think is > logical. if you click a settings entry.. you want that entry up now - if > it didn't exist at all, create it, or if it does, bring it to the front. > > > 4. Setup dialog windows should not be hidden > > Clicking on an option in the main window after maximizing it opens a > > window for the selected settings dialog. Clicking again on the main > > window, it goes to the foreground, and to get the dialog window back, I > > first have to resize the main window and then click on the dialog > > window. > > As there are so many setting options for window behaviour and appearance, > > I guess, this behaviour can be changed. But what would be the right > > setting options? I am at the same time confident that this can be > > changed and lost because of the sheer multitude of configuration > > options... ;) > > just select it again in the config panel. the settings window comes up. Again, it's a different behaviour than what I am used to, and therefore initially unexpected. So no problem, at all, just something I'll have to get familiar with. > > > 5. Menu opening effect > > Sorry, I don't know how to describe this better in English, but I try my > > best. Clicking with left mouse button the desktop background opens the > > root menu. But it isn't just there. It is "blended" in, avoiding harsh > > contrast. The effect is initially visually appealing, but after a while > > I find it a bit too much. (Where) can I turn this effect off? > > you can select another style for the menu "effect". its in the composite > settings (edit the menu style and under style select something else) Worked! > > > 6. Sub-menu not completely shown when on the border of a workspace > > When I move the mouse close to the right border of my workspace and click > > with the left mouse button, the root menu opens up. When I then click on > > one of its entries, the respective sub-menu is opened, e. g. > > applications. But only part of the menu is visible. To see the complete > > sub-menu, I have to move the mouse farther to the right. Then the menu > > and the sub-menu are moved towards the centre of the screen. This works, > > and is, again, visually appealing. However, I still find it more > > comfortable and simply faster the way it's done in KDE: If there is not > > enough space for the sub-menu on the right side of the root menu, the > > sub-menu is opened left of the root menu. Is there a way to get this > > behaviour in E17, too? > > no. there isn't. e's menu behavior is 1 size fits all here. this means > submenus always open in a predicable direction/location allowing for > better muscle-memory. this is in fact a conscious decision NOT to do it > the way qt/gtk do as i have found that way much more annoying as you have > to figure out which way the menu opened this time (as well as having to > adjust the arrow display and so on which looks totally odd when you have > multiple arrows pointing at eachother). also when a menu is wider than the > screen (really low res screen maybe) you cant scroll along to read it with > the "change direction" mode. as well as some child menus opening to the > right, some to the left depending how wide they are. overall not a good > look imho. :) Good reasons. Just because Gtk and Qt do it, and users like me are accustomed to a certain behaviour, doesn't make it the best approach. Let's see, how long it takes, until I get familiar with the way, it's done in e. The advantage of the approach, KDE, Xfce etc. are taking is, however, that you see immediately all entries of the sub-menu, scan it and focus on your target entry. Not sure, if this really takes more time than in e, where I first have to scroll to the right, before I can see my aim. Again, probably just different, and a question of personal likings. I think I'll get used to that, too, over time, and work with it as efficiently and effectively as with KDE. [...] Thanks for your patience! Alex ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
