From: Carsten H. (T. R. <ra...@ra...> - 2002-09-25 03:09:58
|
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 etc.). 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 talk. -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 |
From: Codie W. M. <ret...@co...> - 2002-09-25 04:53:03
|
Just for another perspective here: For the new code, will Evas2 be used for rendering? How should\will the redesign fit in with the rest of e17? --codie Please don't smack my stupidity. |
From: Carsten H. (T. R. <ra...@ra...> - 2002-09-25 05:16:38
|
On 24 Sep 2002 21:52:00 -0700 Codie William Masters <ret...@co...> babbled: > Just for another perspective here: > > For the new code, will Evas2 be used for rendering? How should\will the > redesign fit in with the rest of e17? yes. Evas2 is the thing. it's a much cleaned implementation of evas <= 0.6.0. API is infinitely cleaner. Basically assume everything will change. My personal plans is to test all the code in stand-alone isolated programs - ie - i am planning on doing an entire set of border handling code as a test program on its own that uses ebits2 + evas2 etc. so we can be sure of several things. 1. it's fast & optimal and has a minimum of side effects for the client windows. 2 it's solid doesn't leak or crash - and we don't have the rest of a wm to worry about so we can debug in isolation. > > > > --codie > > > Please don't smack my stupidity. > -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 |
From: Till A. <ti...@ad...> - 2002-09-25 05:40:12
|
# Quoting Carsten Haitzler (ra...@ra...): > 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) Thanks a lot for that. [snip] > EET can handle all the file, image sotrage, and data loading and saving > needs and random access needs. And ewl does the rest already, I believe. I think marrying eet/edb and ewl would yield exactly what you want to do. Right Nathan? Cheers, Till |
From: Carsten H. (T. R. <ra...@ra...> - 2002-09-25 05:54:33
|
On Wed, 25 Sep 2002 07:39:20 +0200 Till Adam <ti...@ad...> babbled: > # Quoting Carsten Haitzler (ra...@ra...): > > > 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) > > Thanks a lot for that. > > [snip] > > > EET can handle all the file, image sotrage, and data loading and saving > > needs and random access needs. > > And ewl does the rest already, I believe. I think marrying eet/edb and > ewl would yield exactly what you want to do. Right Nathan? slight difference - this is where the 2 merge... the gui layout is a descriptor file - not created by code. :) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 |
From: Nathan I. <rb...@us...> - 2002-09-25 06:54:45
|
On Wed, Sep 25, 2002 at 07:39:20AM +0200, Till Adam wrote: > # Quoting Carsten Haitzler (ra...@ra...): > > > 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) > > Thanks a lot for that. > > [snip] > > > EET can handle all the file, image sotrage, and data loading and saving > > needs and random access needs. > > And ewl does the rest already, I believe. I think marrying eet/edb and > ewl would yield exactly what you want to do. Right Nathan? > > Cheers, > > Till Hmmm... Think of this more like glade's relationship to gtk w/o the gtk. ;-) Ie. All layout is handled by the description in the files, so you don't declare and pack boxes, instead you layout an interface in a GUI and give names to certain elements so you can receive and send signals to them. This is very similar in concept to Apple's Interface Builder and .nib (NeXT Interface Builder) files. I've got a large reply in the works to raster's last message, but I'm way too sleepy to finish it coherently. So expect a more thorough reply in a few hours. -- ---------------------------------------------------------------------------- | Nathan Ingersoll \\ Computer Systems & Network Coordinator | | http://atmos.org/~ningerso/ \\ Minnesota Center for Rural Health | | mailto: nin...@ru... \\ http://www.ruralcenter.org | ---------------------------------------------------------------------------- |
From: Alexander G. <a7...@an...> - 2002-09-25 06:21:17
|
On Tuesday, September 24, 2002, at 07:59 PM, Carsten Haitzler (The Rasterman) 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) > [snip] > > 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. > What about the case where you have: pants/... parent/john/pants parent/jenny/pants I realize that multiple ``pants'' aren't unique, but just for the sake of API generality (and extensibility) it might be nice to just implement searches. Being able to not only specify a root, but also the intended bit, so: ebit_list = ebits_search_bits(ebits, "parent", "pants"); .. would return all the pants under parent (i.e. both john and jenny's). You could still do unique bit look-ups: the_ebit_i_want = ebits_search_bits(ebits, NULL, "MyUniqueBitName"); .. but you also have the capability to do more general searching (like finding every ``button'' under a given parent). [snip] > 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.). > [snip] I've been messing around w/ dynamic elements a lot recently, while developing UIs for some of my embedded projects. The type of API I've created uses the idea of having callbacks that are triggered over the duration of some specified time, with the callback's argument being some local data (e.g. the graphical element to be dynamically changed), and the percentage of the elapsed time. For instance, if you want to change the alpha blending of an object over time, you'd register a callback for the duration you want (5000 ms for this example), the local data to send to the callback, and whether or not you want things to reoccur. As your main timing loop happens, the manager of all the registered callbacks goes through its list, makes the appropriate callbacks with the appropriate arguments (i.e. the local data, and the percentage of time passed), and the callback proceeds to update whatever it needs to update. The manager then looks to see if the duration is up, and either removes the callback from it's update list, or if things are reoccuring, it resets the elapsed time, and starts things anew). So, assuming that 1250 ms have passed since the duration timer was started, the callback would get notified that the duration was 25% complete. The callback would then update the elements it needs to, to be in the 25% state. So if you're creating a throbbing text object, at 0% complete the text would be opaque, at 25% it would be 50% opaque, and 50% it'd be invisible, at 75% it'd be 50% opaque, and at 100% it'd be entirely opaque again, ready to start the cycle over. Granted, this might be the way everyone already does things.. I don't know (i.e. this isn't rocket science), but for my purposes it's been really useful. It totally gets rid of the concept of rigidly timed animation frames, and results in things happening in the duration you'd expect, rather than the number of steps you designed. If you've got more CPU, you can render with much higher resolution.. if your CPU is under strain, you get choppiness instead of complete crawl while animation is trying to happen. I'm not sure if this is close to what you had in mind.. but the more I do dynamic elements in UIs, the more I wish that there were common APIs to do these sorts of things. I'm interested in seeing what you're planning. Alexander |
From: Carsten H. (T. R. <ra...@ra...> - 2002-09-25 06:59:26
|
On Tue, 24 Sep 2002 23:20:49 -0700 Alexander Guy <a7...@an...> babbled: > What about the case where you have: > > pants/... > parent/john/pants > parent/jenny/pants > > I realize that multiple ``pants'' aren't unique, but just for the sake > of API generality (and extensibility) it might be nice to just > implement searches. Being able to not only specify a root, but also > the intended bit, so: > > ebit_list = ebits_search_bits(ebits, "parent", "pants"); hmmm ok- so we should include a way of specifying a search start point > .. would return all the pants under parent (i.e. both john and > jenny's). You could still do unique bit look-ups: > > the_ebit_i_want = ebits_search_bits(ebits, NULL, "MyUniqueBitName"); > > .. but you also have the capability to do more general searching (like > finding every ``button'' under a given parent). ok. > I've been messing around w/ dynamic elements a lot recently, while > developing UIs for some of my embedded projects. The type of API I've > created uses the idea of having callbacks that are triggered over the > duration of some specified time, with the callback's argument being > some local data (e.g. the graphical element to be dynamically changed), > and the percentage of the elapsed time. > > For instance, if you want to change the alpha blending of an object > over time, you'd register a callback for the duration you want (5000 ms > for this example), the local data to send to the callback, and whether > or not you want things to reoccur. As your main timing loop happens, > the manager of all the registered callbacks goes through its list, > makes the appropriate callbacks with the appropriate arguments (i.e. > the local data, and the percentage of time passed), and the callback > proceeds to update whatever it needs to update. The manager then looks > to see if the duration is up, and either removes the callback from it's > update list, or if things are reoccuring, it resets the elapsed time, > and starts things anew). that would be the logical way of doing the internals - yes. :) though i'd like to see this be able to be programmable but more importantly definable in he gui editor (just think motion paths in a 3d modeller/animator or even just the color curves in gimp and apply them over time) > So, assuming that 1250 ms have passed since the duration timer was > started, the callback would get notified that the duration was 25% > complete. The callback would then update the elements it needs to, to > be in the 25% state. So if you're creating a throbbing text object, > at 0% complete the text would be opaque, at 25% it would be 50% opaque, > and 50% it'd be invisible, at 75% it'd be 50% opaque, and at 100% it'd > be entirely opaque again, ready to start the cycle over. yup - and the likely implementation would be a purpose-written callback that just looks up the values it is to apply in a table and/or a curve (1d or 2d). :) that's the thoughts i had - yup. > Granted, this might be the way everyone already does things.. I don't > know (i.e. this isn't rocket science), but for my purposes it's been > really useful. It totally gets rid of the concept of rigidly timed > animation frames, and results in things happening in the duration you'd > expect, rather than the number of steps you designed. If you've got > more CPU, you can render with much higher resolution.. if your CPU is > under strain, you get choppiness instead of complete crawl while > animation is trying to happen. absolutely - thats core to the design. the code should be able to auto-adjust to the speed of the machine and its load. if it's a slow box - or is heavily loaded - guess what! your animations go jerkier - but they still take the same duration. the tougher example here would be animation frames of an object lets say the button when you click goes thru several imges depicting its state change over 5 seconds. we'd have a state list (can be used for text too): image1.png image2.png image3.png .... image19.png image20.png now our animator picks a position on this list (form entry 0 to entry 19( depending on where it is in the timeline - this means it will auto-skip frames if it needs to. i propose we can do the same with text: Label 1 Label . Label.. Labe... Lab... La... L... .... P... Pa... Pan.. Pant. Pants so you could have a label of something transition its CONTENTS just like it transitions between images (we are going to have hell here with internationalization). we can transition the alpha value, color font & size, etc. as well. all parameters can transition - using any curve to map time to position of transition too. (ie it is slower at he start - faster at the middle and slow at the end eg: __End -~ / / / --~~ Start > I'm not sure if this is close to what you had in mind.. but the more I > do dynamic elements in UIs, the more I wish that there were common APIs > to do these sorts of things. I'm interested in seeing what you're > planning. Well the idea is that you can hook a callback to the transition if you really want to program it - BUT state lists, parameter curves (applied relative to a sart pos or in absolute terms) should cover 98% of things that people spend a LOT of code on doing that are really is a mindless waste of time for the programmer (well it is once you do it for your 153rd element! and all u really want to do is just draw a motion path form a to b as to where the thing is to fly when you click button c). i'd like to see things like enstrom be able to simply be defined as behavior in ebits. this windows thing where mens slide our or fade in- that should simply be in the design of the element in he gui designer. now anyone can change how things behave and look - without having to know a line of code! they can now select form a pile of data files that will define the look & feel. they can re-design their gui layouts as they see fit! if they don't like ok buttons on he bottom-right they can move them! (and for embedded this means design your program once - and just "redraw" a gui in he designer per target device profile- ie 240x320 design, a 640x200 design, a 144x200 design etc. code si identical as it still just hooks to abstract gui elements and says "when ok is clicked - tell me" etc.) -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 |
From: Moritz A. <mor...@gm...> - 2002-09-25 13:59:12
|
hi all, 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 WIDGET w; 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 widget-engine wide. 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 > etc.). > > 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 > talk. > > > -- > --------------- Codito, ergo sum - "I code, therefore I am" -------------------- > The Rasterman (Carsten Haitzler) ra...@ra... > ra...@de... > Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- - Moritz Angermann / mind - ------------------------------------------------------------------- This message is composed of 100% recycled electrons & photons only! ------------------------------------------------------------------- |
From: Nathan I. <rb...@us...> - 2002-09-25 22:19:55
|
Sorry for the length of this response, but there's lots of stuff to address. If I'm totally off-base on some of these ideas, please let me know. A few people have mentioned they see this plan more as an EWL wrapper. While it could be implemented in that fashion (ie. gtk and glade), there are some very good reasons not to do so. Most of the work in a classic widget library is laying out widgets based on containers. Where the containers use specific layout rules. With this ebits2 scheme, layout is no longer handled by packing widgets, it's all done by the interface designer's description. The packing scheme can be used in a more flexible manner at runtime, but it's rarely necessary to handle the dynamic packing of widgets when you can define relative positioning and sizing. At least that's my experience. Is this a new idea? I don't think so. The Apple/NeXT Interface Builder seems very similar to me. In that system, the entire UI is described in an applications .nib file. It does seem to be a very effective scheme, people that are familiar with the system (not me) can develop GUI apps very quickly. Ok, just to make this easier for me to envision, I broke the requirements list into a few categories and reworded them a bit. File format requirements: * reasonable size * fast, random access of data * references to external data sources * encapsulation of source data Functional goals: * collect individual bit designs into layouts * load entire layout & logic * handle visual and logical behavior of all elements * abstract interface layout from the program * resizable * themable Supported primitives and modifiers: * animation * clipping primitives * re-colouring (color classes?) * solid colour primitives * text primitives * extensible for more items and objects Usage goals: * describe & design window borders * describe & design all normal widgets (menus, sliders etc.) * library to do the logic & loading * gui editor to edit the files > 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 > etc.). I guess I'm seeing this issue slightly different. Currently in EWL we (I guess for the time being "we" == "me") use ebits because we can define a graphical object that can be cleanly scaled. Overall, ebits is overkill for what we use it for, but it already contained the functionality we wanted and at the time, ebg didn't exist yet. The way I picture this, there are four main issues here: 1. Image/Primitive layout 2. Interface layout 3. Text layout 4. Interface interaction Remember, these are just issues I see, not necessarily lines the code should be separated along. Image/Primitive Layout ---------------------- With image and primitive layout, we shouldn't define callback/signal capabilities or the ability to access any single element. These could be considered true bits (indivisible units). I agree that a bit should be able to contain another bit, but only for display, ie. I can create a bit out of multiple images/primitives and describe how it scales, and that can be inside of a bit describing a button as well as describing part of the scrollbar's dragbar. This could also include the various states (although not hard-coded states). Basically, something like ebits now w/o the ability to access individual pieces of the bit, or to attach callbacks to any part of it. These image layout definitions could all be stored in a single eet and allow us to re-use images in different elements of the UI. Thus avoiding an issue we have now, multiple evas cache entries for what is essentially the same image just stored in different bit files. IMHO, these files should also contain fields to indicate their default sizing (possibly with a way to indicate it based on contents?) so that we have consistency in applications laying them out. Interface Layout ---------------- The basic idea is the same, essentially laying out images, but we would want to allow for naming/accessing specific elements of the UI. This would be the level where events are received, and can be passed on to the image bits within each UI element. At this level, each portion of the UI can receive it's appearance by querying the central eet for it's image data, but there should be some means for an application to specify alternate images/bits to be loaded. Maybe something like a URL to access the data, ie. config:/ indicates retrieve from the central theme, file:/ retrieves from a specific path. As well as means for changing this at run-time for portions of the UI, so you can show theme previews or different theme sets within portions of the app. Another requirement for interface layout is nesting layouts, and a means to describe position offsets as children are added (think tables, lists, etc). I'm not sure if you have something in mind to handle this internally to ebits2, but this may be a good fit for EWL with ebits, ie. a layout engine for portions of the GUI that are dynamic. Text Layout ----------- This is really an issue I'm not familiar with once i18n is considered. Putting text at the bottom level bit probably would not work, at least for the case where text needs to be changed. Defining text at the interface layout level makes more sense to me. There we can set elements containing the text to be sized relative to the text, and still have a clean separation between what is a "bit" (can change state/value, but can't be divided into individual elements) and what isn't. Otherwise, a split in text handling, moving non-modifiable strings into the image/primitive's layout, and having a modifiable type of text that fits into the interface layout category. Somewhere inside there needs to be some means of laying out text correctly, even as it changes through input. Interface Interaction --------------------- Now we get to the complicated part of the situation. Processing events is easy enough, but now we need to design a system for describing variable changes in the interface based on events. Things like the animation curves you mentioned, how to describe them (keep a polynomial and coefficients? what about other curves like cos, or exponential? estimating them through polynomials?), as well as triggers for these events. In a slightly different vein, there is the scrollbars which act inversely to the contents they scroll (ie. dragbar gets smaller the larger the scrolling area, moving dragbar down slides contents up, etc), while a relatively simple ratio defines the relationship, it does have a few variables. To accomplish all of this, it seems like we would really need some sort of embedable scripts to handle the various functional tasks that would be involved. Ok, that's the ramblings that went through my head after reading your message. My opinion is that this should be the basis for e18. We have a basically usable window manager right now and if we were to finish some of the items listed at: http://www.twistedpath.org/~term/e/features.txt - without some of the features, we could release something relatively soon. This ebits2 idea is going to be a long-term development, but could result in an extremely functional GUI build system. So if some of us got the current code whipped into shape, we could release it, and move onto a new code-base involving ebits2. Thoughts, comments, flames? RbdPngn -- ---------------------------------------------------------------------------- | Nathan Ingersoll \\ Computer Systems & Network Coordinator | | http://atmos.org/~ningerso/ \\ Minnesota Center for Rural Health | | mailto: nin...@ru... \\ http://www.ruralcenter.org | ---------------------------------------------------------------------------- |
From: Carsten H. (T. R. <ra...@ra...> - 2002-10-21 21:52:25
|
On Wed, 25 Sep 2002 17:19:46 -0500 Nathan Ingersoll <rb...@us...> babbled: [... SNIP ...] nice and long. thanks for the responses.. i've thought this over and i think RbdPngn might be right. ebits2 and ewl are very close. they might be best to be rolled into the same project... but should be done in parallel and aimed for e 0.18. in the meantime we should nuke ebits from the current e17 code (i don't want to pretend to have a system we'll keep using when we won't) and make e17 have a very basic config system for now and finish off building the wm with basic visual config ability and work in sliding in ebits2/ewl for e 0.18. so what do you think? this would mean: 1. e17 will actually get released within a decade. 2. we have simplified the problem space for e17 and thus sped it up. 3. we get to test out other subsystems etc. in the meantime. so right now i have ecore set in my sights for a bit of an overhaul... fix up some api calls, make them more generic and powerful, fix up the naming of some obscure ecore calls etc. -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 |
From: Hall S. <hal...@mi...> - 2002-10-22 12:17:51
|
>1. e17 will actually get released within a decade. Oooh, the best estimate so far of when we'll see a "released" e17 !! ;-) |
From: Cristalle A. S. <ed...@az...> - 2002-10-21 23:19:53
|
Carsten Haitzler (The Rasterman) writes: > ebits2 and ewl are very close. "Not in front of the children." > they might be best to be rolled into the same project... "Told--", er, "excellent suggestion!" > and make e17 have a very basic config system for now and finish off > building the wm with basic visual config ability and work in > sliding in ebits2/ewl for e 0.18. [hence] 1. e17 will actually get > released within a decade. 2. we have simplified the problem space > for e17 and thus sped it up. Not sure what TOD it is in Oz, but you've seen the light. : ) ducking, Azundris |
From: Carsten H. (T. R. <ra...@ra...> - 2002-10-22 01:51:56
|
On Tue, 22 Oct 2002 01:19:42 +0200 Cristalle Azundris Sabon <ed...@az...> babbled: > Carsten Haitzler (The Rasterman) writes: > > > ebits2 and ewl are very close. > > "Not in front of the children." > > > they might be best to be rolled into the same project... > > "Told--", er, "excellent suggestion!" > > > and make e17 have a very basic config system for now and finish off > > building the wm with basic visual config ability and work in > > sliding in ebits2/ewl for e 0.18. [hence] 1. e17 will actually get > > released within a decade. 2. we have simplified the problem space > > for e17 and thus sped it up. > > Not sure what TOD it is in Oz, but you've seen the light. : ) tod... he'll be one of the guys down @ the pub... :) but this does mean we have to/can bring forward work on e17 itself. i personally would like to start again - strip the useful things form e17 as it stands and so we can have a minimal codebase to do just the basics and go from there... -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) ra...@ra... ra...@de... Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9698 8615 |