On 25 Oct, Pfeiffer Daniel scribbled:
-> In changing from fvwm95 to E (16.4, 16.5 is just to darn hard to install
-> without replacing half my Linux distribution -- SuSE 7.0 which isn't even
-> two months old), I'm stumbling across a few things which are kludgy in
-> fvwm95 but seem impossible in E:
-> I have a few key combinations bound to my most important windows (emacs,
-> Netscape, StarOffice ...). When I hit this key I automatically change to
-> the desktop and area where the window is and give it the focus.
-> I have a menu of all the Unix hosts I have to access regularly. If a window
-> with that name exists I change to it like above. If none exists I exec one.
-> An extremely nice feature in this context would be modifiers for menu items.
-> They'd work a bit like mouse selection modifiers in Gimp. I.e. irrespective
-> of the modifier needed to get the menu (which I can unpress as soon as the
-> menu is there) I'd then press another one to have the same menu item perform
-> various tasks.
-> As far as I understand windowmatches.cfg, it says "given a window of kind X,
-> apply some style attributes to it". But I need to combine this with
-> reacting to an event with some action on a window of some name, title or
-> class. How can I configure these in E?
-> Another thing I'd like to have is only one pager, which always displays the
-> current desktop.
only use 1 desktopand use virtual desktops then. you can also make your
pager windows borderless and drag them intoa corner or something -
edge resistance makes it easy :)
-> Also a few bugs: If the font specified by a theme is not installed, it
-> doesn't display text, making titles unreadable and menus unusable. X11
-> convention is to fall back to "fixed" or something in such cases.
yup - that's right. fixed isnt always a soltuon as the size of the area
he font can be put in is very dependant ont he font size - titles arent
sized according to the font. E does nto follwo conventions - it breaks
-> While X11 has had wide (2 byte) fonts forever, a few applications like
-> Netscape and, alas, Enlightenment cannot handle them. They then display all
-> characters as empty boxes instead. This prevents using most Truetype fonts
-> which are a (bigger than Latin-1) subset of Unicode.
yup- the trutype font wrapper is incapable of doing 2byte fonts. i am
still waiting for efficient patches to imlib2 (and now evas) to do this
as i am no font/text expoer with unicode and text formatting for the n
billion languages out there that ay format left to right, right to left
- or both (ie hebrew) and those that chnage their characters depending
on context of the sentence (arabic) etc. i onyl support 1byte fonts
because the glyph lookup array is onyl 256 elements (thats 256 pointers
- so 1kb) - for 2byet it'd be 256kb - and the majority of people still
use latin1 fonts and to suddenly force peope to have an extra 255kb per
font in memory is not on my cards - so figuring a fast way of storing
glyph lists in a small memory space for only glyphs used and fast
lookup mechanism would be on the cards...but again - i'm not going
there as i'm no expert. also i'm used to munging strings 1 byte at a
time - i'd have to chnage a tonne fo code to munge them 2 bytes at a
-> As a related bug, the menu and submenus generated by e_gen_kde_menu are
-> empty, maybe because you don't yet handle UTF-8 as all KDE configurations do
-> now. And the title is in English, although my KDE is configured for
-> A completely unrelated idea concerns the borders: Title bars on the side
-> are so neat! But alas every theme does something different. So changing
-> themes mostly breaks all remembered window styles. It would be extremely
-> cool if E could mirror and rotate border styles: from one specification E
-> would create 8 different borders: top left->right, top right->left (buttons
-> and layout, not text), left bottom->up, left top->down, bottom left->right,
-> bottom right->left... Themes would only have to supply those graphics which
-> cannot be automatically adapted nicely.
thats a lot harder than is sounds.
-> Also it dismays me to see various themes which only differ in the colour
-> tone. It'd be great if the color scheme were parametrizable, like turning
-> orange to blue. I'm not sure if this is easy to do on the fly (Gimp can do
-> such filtering of images). This should be on a global or, if selected, on a
-> per-window basis.
color modifiers weren't very well implimented in imlib2 thus i wasnt
able to really support that. even e17 will not do it easily (currently)
though to some extent ti could allow for tinting (evas does allow for
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler) raster@... raster@...
e-develop mailing list - e-develop@...