here is some that might be of any intrest.
my thoughts. ( to be used as ebits!?? )
well you don't have to adoped them but this is an idea
i have no idea how to do that 'exactly'
but i allready teyed a lot and faild due to too less time
and logical problems.
i've talked about this with rdbpng(s?) refered as
AUIA[ Abstract User Interface Architecture ][ OR WHAT EVER YOU WANT TO
CALL IT, I JUST NEED A NAME FOR IT :) ]
the idea was, to have a '''theme''' engine like thingy, that also
handles widget layout. so like the coder doesn't even have to know where
the widgets will be placed. he will just do something like:
// i know my c is so bad cuz i have to write a lot of ITG-Pascal for
school and do PHP otherwise
w = auia_request(WIDGET_TYPE); ( returns true/false if not existant )
than he can modify values of w but
he doesn't tell w in anyway how it's displayed.
the widget display style is defined in an ebits!??
and also the window display style is defined in an ebits!??
like: ebits->menu = top; ebits->statusbar = buttom, etc.
maybe relative values!??
maybe you get the idea.
someone said there was somehting on OSX which did that kinda stuff.
but as far as i understood, that's not what i want.
the idea is to have ONE ebits for window layout which will than be
WindowManager/DesktopShell wide, ONE for the widget layout wich will bee
i don't know in how far this might merge!? and in how far this whould
interfere with the ebits
but i suggest to have the THEME and AUIA[ or what ever you want to call
it ] ebits be seperate, not in ONE. cuz that might blow up the size of
the bit and mostly make it cover 'trash'/unneeded data.
i hope i got to manage to put my thoughts forward.
i know this i A LOT of mind batteling.
Moritz Angermann | mind
- http://e1x.mine.nu -
On Wed, 2002-09-25 at 04:59, Carsten Haitzler wrote:
> We need to discuss ebits. it's going well beyond any of its original design...
> so i've written this up as a way of starting a discussion on it's design before
> we go anywhere (and where everyone can ask questions)
> Ebits2 Design Document
> Q. Why?
> A. Why do we need ebits2? Ebits2 is the working name for a replacement
> library/api/file format that is going to replace ebits in its current form.
> Ebits was designed to do window borders for E 0.17 - but is turning out to
> be doing much beyond its original design specifications.. It is becoming the
> basis for user interface desing for scrollbars, launchers, dialogues, menus
> and much more. Ebits as it stands simply isnt designed to expand to this
> level, so before things get too bad, it's time to stand back and fix things.
> Q. Ebits2? We never got to 1.0?
> A. Ebits2 is just a working name. One thing we need is a new name I think,
> so people don't get too confused, as this library willl probably only barely
> resemble ebits only by the virtue that it will take over its functionality
> and much much much more.
> Q. Well what do we need?
> A. That is what this document is about. I will go into detail about my ideas
> so far - but they are to promote thought and discussion and get everyone on
> the same page. This is VERY important, and will likely form the basis of
> much of the E UI subsystem and beyond, so getting this right is essential.
> Now to a list of requirments:
> * has to be able to load entire layout & logic from disk file
> * has to be able to source data for everything from the same file if needed
> so to avoid messy installation trees
> * has to keep data files reaqsonable in size
> * has to be abel to access data file at random, fast
> * has to be able to refer to data outside the data file for themes etc.
> * has to be able to describe & design window borders
> * has to be able to describe & design all normal widgets (menus, sliders etc.)
> * has to be able to collect such design in layouts
> * has to be resizable
> * has to be able to handle the visual and logical behavior of all elements
> * has to have an abstract interface to the program so it doesnt always need
> to know about the layout of items
> * has to support animation
> * has to be extensible in future for more items and objects
> * has to support text primitives
> * has to support clipping primitives
> * has to support solid colour primitives
> * has to support re-colouring
> * has to support theming
> * has to have a library to do the logic & loading and a gui editor to edit the
> ebits2 files
> ....possibly more requirements...
> How to meet these:
> EET can handle all the file, image sotrage, and data loading and saving
> needs and random access needs.
> Let's for the moment define what a "bit" is. A bit is a collection of 0 more
> more primitive objects (text, image, rectangle, and other bits etc.) that have
> a bounding rectangle location and size. The objects are laid out within this
> rectangle according to properties set on them. We can deal with this
> collection as a single unit, move, resize, raise, lower, hide, show,
> re-color etc.
> By the above definition bits can be nested. This means at the very top level
> every ebit file is 1 bit that contains more primitives (images, ext, bits
> A bit has a string name that is assigned when it is created. What do we do
> when there is more than one bit of the same name? We need to address it like
> we address a file path. Let's say we have a parent bit called "parent" and 2
> child bits called "john" and "sarah". the child bits both contain button
> bits called "button". so to address the butotn bit in john:
> "parent/john/button" would make sense. to address the butotn but in sarah:
> "parent/sarah/button". Now we have a new problem. What is an ebit contains
> multiple children of the same name? Let us assume that our ebits will
> contain ways of organising children in a way they can be addressed somehow.
> Let us assume we have a list of children inside "john" that are all called
> "button". This list may be horizontal or vertical or any shape, but it will
> have a start and end, thus we shoudl be able to refer to them by:
> "parent/john/button.0" to refer to the first one, "parent/john/button.1"
> for the second etc.. What ifit is not a linear array but a 2 dimensional
> table of buttons? "parent/john/button.2.7" for the 3rd column, 8th row entry.
> What if we try addressing members of a table by a linear addressing mode?
> let's just linearize the table bu addressing children from top-left to
> bottom right, row by row. Even if it's a table and has mostly children
> called "button" but some called "pants" we could happily say
> "parent/john/pants" to address pants - regardless of where it is in the
> table. We can address a button with "parent/john/button" but it woudl be
> undetermined which button will be referred to - so let's say just the first
> child called "button" that is found is used in this case.
> I have gone on for a while about a naming and addressing scheme. Why? This
> is what I can see as a way of hooking to events on particular bits and
> finding out where singals came from - you know by the full "path" name of
> the object.
> Before I go much further let me quickyl describe what I'm thinking:
> ebits_callback_hook(ebits, "parent/john/button", "clicked",
> callback_to_call_when_button_in_john_is_clicked, NULL);
> So in this case if the bit thats is referred to as "parent/john/button" emits
> a named signal of "clicked" the callback specified is called and passed a
> data pointer of NULL.
> how can this be good? What if you want to know if ANY child bit of john
> emitted a "clicked" signal. Easy:
> ebits_callback_hook(ebits, "parent/john", "clicked",
> callback_to_call_when_anything_in_john_is_clicked, NULL);
> That means that if john, or any children emit "clicked" this callback will be
> called. Versatile, isn't it?
> I also propose that names do not HAVE to be fully qualified path names.
> For example if I refer to the bit "pants" as per one of the examples above,
> without saying "parent/john/pants" and pants is not a top-level bti, ebits
> will walk the bits tree down from top to bottom finding the first bit called
> "pants" until it is found. If these names are unique thewn the right child,
> no matter where in the tree, will be found. This lets the layout be easily
> changed and parent/child relationships can also change and the code will
> still work and find the right bit to access.
> We need to make sure our naming/addressing scheme is consistent, flexible
> and easily understood. I have proposed this idea as above for now - but any
> modifications or other schemes should be discussed. The actual names of bits
> and the trees will vary from bit to bit that is designed - but we need to
> support all the right things.
> When you look at this, this begins to look like a widget set and a widget
> tree - with names for widgets etc. If you have ever seen glade - this looks
> a lot like this. If you haven't used glade before, I'd suggest you play with
> it and get to know it well for the purposes of this discussion.
> Now we know that this is a tree and that elements (bits) have names and can
> emit signals, we can discuss more on how they work.
> Bits also have states. States are named as well. "clicked", "disabled",
> "busy" are a few examples. Each state is defined in the bit as the
> parameters of all its constituent elements (are they visible, their size,
> location, color & alpha, the images used, fonts, text contents etc.). A bit
> can be in any state (but only 1 state) and a bit can transition between
> states - that means that the parametrs will be interpolated from the current
> to the new state. How this is figured out will depend on the type of
> parameter. Visibility is boolean. Text string is too (it can be one or the
> other). Some other parameters (location, size, color etc.) can slide and
> thus can follow a curve while transitioning. Curves come in varieties, but
> an ebits file can list a set of known curves for motion, size and color
> change and these curves can be named and referred to by name. All of the
> transition curves should be able to be applied in absolute terms (ie
> determine the position, size and color) or relative (ie modify size,
> position color etc. by the amount the curve specifies from the current state).
> You may notice I'm a bit vague here, but I'll have to clarify what I mean
> here a bit later on - but I hope you get the drift (Think of the 3D
> modellers where you can specify motion paths for objects over time etc.).
> We also need to realize that now the text contents of objects can be defined
> in ebtis files - we need to solve internationalization at this level.
> Basically we need to encroage the use of "standard phrases" (such as OK,
> Cancel, Open, New, Save, Save As... etc.) so that the translations only need
> to be done once and all elements using that phrase in Ebits (or in any other
> code) can share the translated phrase. Designers shoudl be encouraged to use
> the standard phrases where possible - and when it's not possible, submit new
> standard prhases so they can be translated too. We have little or no need to
> use gettext as 1. all the infrastructure to do this is already provided by
> edb and eet, and 2. gettext is becoming a pain in the arse to support.
> By virtue of the standard phrase catalogue - we need to introcuce the idea
> of standard icons, images, colours and ebtis catalogues that can be built,
> used, recycled etc.
> Parameters of ebits elements need to bve programattically settable and
> query-able. The best examlpe of this would be for slidrs, scrollbars etc. We
> need to encapsulate the basic logic behind these kind (and more) widgets as
> part of ebits so it's possible to build such widgets simply as primitives in
> ebits. We need to cover all known common widgets - and then maybe even more,
> in the hope of covering all territory that we will likely need to ever cover
> in future.
> Now... let's see if we can solidify some of these ideas in a design - let's
> --------------- Codito, ergo sum - "I code, therefore I am" --------------------
> The Rasterman (Carsten Haitzler) raster@...
> Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> enlightenment-devel mailing list
- Moritz Angermann / mind -
This message is composed of 100% recycled electrons & photons only!