I have experimented extensively with the shelf technology and look
forward to further development. It is just that usually I can see the
why and wherefore of some development but in the case of the shelf
technology I couldn't. If as has been suggested in another post it will
ultimately make module development and functionality easier then that's
great.
As I said I was just curious. I figured that a group that produced e17
(which is the best UI around I feel) must have a reason for following a
specific path and I just couldn't see it.
For what it's worth I am amazed that a diverse group that is spread all
over the globe can do so much in such a small amount of time!!
Jim
Michael Jones wrote:
Currently, you can also do as was suggested last week in a message to
the list and set the shelf to "Below Everything", style Invisible, and
add modules to that way, changing the size as you wish. Granted, this
will probably place them along screen edges only, but for now it
works. Plans to fix that are already in the code so it shouldn't be
long before you can do more advanced positioning.
- Mike
/*
Michael Jones
[EMAIL PROTECTED]
*/
/On Friday, May 26, 2006 at 8:26 am, Jesse Luehrs wrote:
/
---- Original message ----
Date: Fri, 26 May 2006 09:00:53 -0500
From: MillTek <[EMAIL PROTECTED]>
Subject: [e-users] Question about the shelf?
Cc: [email protected]
I am curious about the rationale behind the shelf or shelves.
Previously
I was able to use the standard 'edit' feature of E to move a
module's
display to any place I chose on the screen(s). Now, as
modules are being
converted to work with the shelf technology I find that I
have to either
stop using a module (say, the cpu temp module for example) or
activate
it within a shelf. The shelves are restricted as to where
they can be
placed and are limited to the edges of the screen.
As it stands, I find e17 to be one of the most well-designed and
functional interfaces I've seen. The shelf technology seems to be
introducing a degree of inflexibility that runs counter to
the freedom
available elsewhere in e17. Am I missing something about the
concept? Is
there an advantage that I just am not aware of?
Just curious,
Jim
The advantage is a much simpler codebase, with a lot more
shared code, making for much simpler development. This isn't
inherent to the shelves, but to gadcon, which is the new
replacement for gadman. gadman is what used to handle gadget
(the visible part of a module) placement on the screen, but it
had some design issues which are resolved by gadcon. The shelf
isn't inherent in the gadcon design, it's just the first
implementation of a gadcon container... from what I
understand, once the shelf is complete and all modules are
moved over to gadcon, raster will write up a few other gadcon
container types which will allow for all of the flexibility
that gadman had in module placement (someone can correct me if
I'm mistaken here).
Jesse
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
enlightenment-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
enlightenment-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
