Not at this time, with a single instance.
Just by looking at the version numbers (ie, less than 1.0.0) you will see that most of what makes Enlightenment what it is, is technically beta, and how far it has to go to completely encompass the vision of the developers. Mind you, the "bare minimums" that exist today are very stable, and if you've experienced Enlightenment before, then you'll come to accept that it has come a very long way, indeed. If the word "beta" scares you, or the X Server that Enlightenment will be installed on is mission critical, perhaps you should try it on another system first like you would any other unfamiliar code base. The Enlightenment developers are quite serious about their development releases and how long its cycle will be... so don't hold your breath waiting. Jump in and swim, or watch.
Please note that these totals are the result of my personal system and may be much larger for binaries and libraries than is considered normal. Do not interpret these as gospel, only as a guide to what you can expect. As you can see, most of the space used is for raw graphics and sound bites, and can be selectively used or discarded depending on the customization you choose to expend energy on, and will probably be reused in a number of themes.
You could always strip all of the debugging symbols from the binaries if you want to. They are only useful if you wish
to debug Enlightenment or send in bug reports to the mailing list or developers. Otherwise, removing them is
harmless and can could possibly save you some disk space if this is a priority issue to you. Type
strip /usr/local/enlightenment/bin/*. Please disregard the warning it generates, as it is concerning the
non-binary Perl script format of ConfigEdit and its inability to change such. If you thereafter wish to send in
bug reports, you must recompile Enlightenment and reproduce the error.
There are plenty of ways of doing so. No doubt you've heard from the developers themselves that these are development releases, and as such come with no warrantee of "nice" behaviour. Enlightenment might crash, and this is what running software in a development cycle is sometimes about. While I personally don't think that there is much to worry about, some people have things that are very important to them and would rather not incur the possibility of data loss for any reason.
However, there are ways to minimise your discomfort after a "crash." The major limitation is that you cannot depend on resultant windows being raised and managed; the idea is then to fulfill the running tasks you need to, grab your data, and RUN. Sometimes this can be done safely with the Restart button with no loss of state, but sometimes not. The following are working suggestions to improve your worst case scenarios:
nohup to run all of your programmes that do not need supervision but that you still want to run
through, and after you recover from a crash uninterrupted. This requires that the programme
have a tty or file output option, however, to serve as a logging feature.
This list is not inclusive or definitive, and possibly includes dander and fluff in it as well; but these will probably be the likely feature set in Enlightenment's next development cycle.
Iconisation allows a window to be shrunk into an iconic state where a very small pictogram replaces the actual representation of a window's display. Clicking on this icon will bring about a usable window display and place it in the same place as it was previously iconised from. Iconisation is useful in that it clears up usable work space for programmes that do not necessarily need user display and interaction at the same time space is needed. More than one icon be on any desktop, and these may be moved around at your pleasure.
The icons themselves can be overridden for specific programmes and replaced with others of your choosing. Each icon is within an Enlightenment defined graphic that acts as a graphical backdrop so that the iconic pictogram is more distinct from the root window background.
While the theme-controlled and user-controlled portions of your Enlightenment setup are easily changed
with any text editor as they are human-readable textfiles using an easy-to-understand theme language,
Enlightenment has given you the option of having a GUI tool to do the same thing. While still in
need of development, ConfigEdit is included in the Enlightenment package for you to peruse and experiment
before you wish to dive head-first into the theme files. Call it by typing ConfigEdit; a GTK
application should pop up and lead you from there, if you have Gtk-Perl and GTK installed.
Another method for changing your themes in a GUI framework is with the newer (post-0.30) versions of GNOME Panel that are currently in development within the CVS tree. Authored by Raster, it will hopefully reach the usage level of more users and seem to be designed for convenience rather than systematic gritty detail level items that a theme designer would use. It lives under the System menu, and is called GNOME Control Centre.
There is a thematic option to allow the changing of shaped graphic sizes, so that the graphics may be sized as well as shaped given any normal action that may other wise change the graphic display, such as mouseover and button pressing. This option recalculates the graphic sizes and thus requires slightly more processing power and needs to be turned on in a given theme that makes use of it, otherwise all the graphics are presumed to be the exact same size as the default, or normal, condition as will be shaped and sizes accordingly. This allows buttons to "stand out," window graphics to change into something literally different when in used or not, and a number of other things.
This feature of Enlightenment allows non-rectiniliear graphics to be combined and shaped for any graphic representation that may be displayed, including window borders, buttons, and whatnot. This is the feature that allows the use of odd shapes that may partially overlap. It also goes without saying that this leaves how windows fit together ultimately up to the graphics themselves. This is achieved by using the alpha channel, normally known as the "transparency colour," to affect this outcome. Unfortunately, the more rectangular shapes that are needed to "outline" with each graphic virtually to achieve the shape, the more processing power is needed by the X server, and thus the slower it will be, relatively speaking.
As themes change from a different "style" of overall look and feel, so too can the border style of each individual class of windows be changed to better suit your needs. Within each theme configuration file you can define any number of different classes of windows that have an individual look and, to some extent, feel. The number of buttons and other gadgets, what they are, the graphics, and other things normally defined by theme can now be attributed and defined by border style. As an example of this capability, the default theme differentiates between terminal windows as a class, and all other windows.
In some way, they are almost a form of iconisation, except that the window border that acts as an "anchor" for the window remains and it is not a representation, but an actual window as a result: only rolled up. This means that normal window operations can still affect this window as a normal window would be affected. (As a sidenote, try using the window shade, and then iconising it--it will de-iconise in its rolled up form factor.) The window shade may be rolled up in any direction that the window shade button is anchored against. In the default theme, this means that terminal windows will roll "up" sideways, while non-terminal windows roll upwards, as the buttons are on the left and top sides, respectively.
A WindowMaker dock is a feature to better utilise WindowMaker-designed applications in Enlightenment to their fullest extent as the WindowMaker window manager would. What this means in particular is that any programme that is designed to be docked to the WindowMaker dock can instead be used similarly with the Enlightenment dock. Just run the programmes you want to use, and watch what happens. Nothing more is needed in order to use these as they were originally intended. You can set them up to run <@@ref>wm_startupautomatically at startup if you are so inclined.
Enlightenment always tries to please its users with gratuitously useful features. TrueType fonts are no exception. They are included because they provide yet another complete class of font selection for you to choose from. TrueType fonts originally found their way onto the Windows desktop, and will provide a larger selection of "conventionally" available fonts for you to choose from. This feature directly ties into the Freefont library at present, and therefore requires it.
Just about what they sound like. You press a button, and they scroll outwards much like a sliding drawer would, and presents a number of other buttons for you to choose from. This is a useful feature if a theme design or border style wants a minimal amount of buttons always shown, or if the window border is shrunk to a point where only one button is normally visible. The buttons that slide out can be otherwise hidden buttons. The speed of the scroll action can be user defined.
Tiled graphics are those that are smaller than the layout allocated to the graphic. The remaining space is divied up into similar sized "tiles" which are then filled with exact duplicates of the image used for the original area. The other option that graphics can use is for the remaining space not to be divied up at all, but the entire image stretched or shrunk to fit the entire area, scaled whether the image is smaller or larger. There are obvious advantages of using one method or the other, the most obvious being that you don't need a graphic that "fits" the area at all. The most obvious and noticeable disadvantage is that sometimes the graphic will be stretched too large to look aesthetically pleasing scaled, in which case tiling is the most appropriate form. Algorhithmically this is sometimes difficult to ascertain and is thus left to the user's and theme designer's tastes on a case-by-case basis.
The usual use of a root window is for there to be one, and only one. FVWM and its descendants WindowMaker and AfterStep scroll this one root window around to offer you more room. The old DR-0.13 era Enlightenment allows you to have multiple desktops with the help of a pager and/or little screenshots of each. The new and improved Enlightenment offers you floating desktops instead of all this.
Imagine a root window. Then imagine another on top of it, and so on. Then imagine each root window as being a pane of glass that you can either see through, slide partially open, to see the other root windows beneath it. Now imagine any number of them partially open for easy access.
Since your imagination is so keen for new ideas, imagine being able to drag windows between these partially opened desktops. Open three at a time, and plop that window to the desktop you want. That's about the only way I can think of telling you about floating desktops; they are far more easy to experience than to explain in an abstract fashion.
They can be slide around in any direction by user fiat, and this direction may be changed on the fly by the press of a button. The sliding can also be made instantenous or you can watch your desktops slide across.
While the usual appellation for this feature is typically called "sticky windows" by other window managers, calling them "floating windows" will seem more intuitive in light of how floating desktops work. Specifically, floating windows are windows that do not slide with a floating desktop. That is, they float independently of anything behind them, much as floating desktops themselves do. As a point of fact, they float on top of the the topmost floating desktop and will thereby seem visible from all floating desktops until the window in question is made normal again, and results in it immediately dropping as a normal window on the currently visibile desktop.
If a window is too large for your monitor to display in one go, chances are you will end up lacking some of the window borders that you need to better manage said window. Likewise, you might want some extra room on a given desktop and do not wish to disturb your current setup, but rather want to just "shunt" it over a bit in a direction of your choice.
By holding down Ctrl, and hitting a Cursor key of a given direction, you can move all the current, existant windows on a desktop. This obviously includes windows that have no frames because they are too large, and windows that are already off, or partially off, the screen from previous use of this feature. The only trick to this is that you are moving the desktop, not the windows. This is reflected in the direction of the cursor key being the opposite of the window movement, as it is instead moving the virtualized landscape of the desktop itself in that direction.
Floating devices and widgets, like floating buttons, the desktop dragbar, and floating windows and suchlike will not move along this axis, or any other, as they are floating about thte desktop proper. Other windows and buttons subject to this movement will instead move underneath the floating objects in question.
For those not content for the abrupt entry of a window, this is your feature. While not strictly necessary for a window manger's existence, it can provide a possibly necessary bit of "eye candy" for novice (or power) users to see when a window is actually spawned. If this user-decided preference is chosen, a window will not immediately be raised and pop up, but rather come from a random corner each time, and literally animate across ("stride") to its proper destination. This will obviously be as slow or as fast as moving an opaque window would be under normal circumstances in Enlightenment. I think it would be interesting to collate some data about how physically useful this is to those who have seizures from large instantaneous changes in screen visuals.
Dox is Enlightenment's own internal documentation system. It can display graphical-orientated Fnlib-style fonts with graphical backgrounds. It has limited hypertextual capabilities and can have any number of graphical buttons with which to navigate between its pages. The major difference between its hypertextual capabilities and other systems' is that Dox is entirely paginated in its rendered. This means that pages are actually numbered and referenced by the user or the buttons. It is lightweight both in its memory use and processing requirements and can have inlined graphics for its buttons and non-functional displays. Each document defines the graphics to use, as well as its own window decorations and page turning abilities.
Themes are defined using an extensible and user defined theme definiton language. While that may seem like a desert of a description, Mandrake has really created a method of defining a definition language with his Stringlist routines. Most people, however, will lack the courage to use their own words to define certain actions and use the ones encountered in the default theme as an ease-of-use tip of the hat to the lay user wishing to make their own changes to a theme. So in effect, what we are talking about is how the default theme defines its language, and that is both very readable and class orientated so as to be taken in digestible chunks. This means that Enlightenment theme langauge can easily be changed to include any Terran (or non-Terran, why limit ourselves?) language or jargon.
With the advent of some of Enlightenment's features, some abilities of external programmes that have normally filled a niche or two have been dislodged because of incompatibility, lack of awareness of the Enlightenment environment, or both. The theory goes, that if they could communicate directly with Enlightenment, they would be able to continue functioning as well as before, or better and bring you some external features that wouldn't ordinarily be available in a "stock" Enlightenment, much in the way they fulfill their niche with other window managers.
There are several areas of influence that will react differently than other window managers. The first is the root window: we have many, and and root-background painter will only influence "Desktop 0", or the first root window you encounter upon bootstrapping Enlightenment. Another is a matter of setting the correct hints to "fall into" the proper area of the screen that might be different than expected because of semi-permanent floating buttons. It can also let you command Enlightenment as a user would: restart a given theme, jump to a particular desktop, that sort of thing. It can create and pass clients and pixmaps to E, delete or retrieve them, and get a list of currently running clients (and all of their Enlightenment-recognized attributes including their borders).
Not bad, eh? Right now, the bindlestiff of its implementation is within Enlightenment itself, but
there is an "example" programme that lets a user give Enlightenment these commands via a command-line
with the newly included eesh. Remember: this is an E15-CVS feature, and not available in
E14.
Have you ever forgotten which Enlightenment widget does what? Or downloaded a new theme and all the graphics and positionings of your usual array have changed and bumbled your way through "learning" the new theme's idiosyncrasies?
That's okay, we all do sometimes. Tooltips are there to make that learning curve nonexistent. They make a little temporary dialog window appear that tells you exactly what you want to know when you pass over something. They don't have to be intrusive if you don't want them to be: there are timer settings, toggles, and other controls available to make sure they don't interfere with your work or fun.
The dialogs themselves are shaped, and in the default theme, are amusingly displayed as thought balloons with puffs emanating from the widget you have your pointing device over.
Yes. This is a good way to centralize some of setup, or are constrained in the machine you normally work on, or use a machine as an X terminal in order to make use of Enlightenment on a platform that you ordinarily don't have access, capability or resources with which to install and run Enlightenment on.
One of the major drawbacks to using a network is that most themes tend to be highly graphical, and these will influence the responsiveness of your network, much like using any normal X11 application remotely would, except raised by a few orders of magnitude if the graphics are similarly a few orders of magnitude above your normal use of X.
Right now you might describe the Enlightenment development team as a tight-knit duo by the names of Raster (alias Rasterman AKA Carsten Haizler) and Mandrake (AKA Geoff Harrison).
They have been working together since the release of Enlightenment development release 0.9.0, and have brought their relative strengths together to good effect: Raster designs the graphics routines and graphics, and prevails of the source code his Australian charm and creativity. Mandrake handles backend coding, the overall coding structure, and his love of Bass ale and Perl (not necessarily listed in order of preference).
Yes, and although the mailing list is there primarily for the developers of Enlightenment, Enlightened and Imlib-based applications, there is room for some intelligent questions and proposals from the "laity." But be warned, that its primary and official purpose is not to field frequently asked questions already listed within this document, and a certain modicum of protocol could give you a more beneficial light on your queries. Make it interesting for the developers if you can. Don't whine and do look ahead at what your suggestions would do to others and whether it would even work in the framework of X11R6. I've also noticed that rhetorically-phrased questions have a habit of not getting answered very quickly.