Comments on: GUI Survey - Do you want panel embedded styles?

Ok, while we wait for an actual name to be picked for the R3 GUI, it's time to start talking about a few things...

Question: Do you want embedded style definitions in panel blocks (layouts)?

In my current GUI implementation, you add styles with the stylize function, similar to R2 VID. I've not yet added the style command for local styles within a panel, because I'm not so sure we want to do that. It's only useful if you use more than one face with that style within your panel.

If we did add it, it would look something like this:

panel [
   example: style 'parent-style [spec goes here]
   ...
   example "here it is"
   example "there it was"
]

This defines a new local style called example and uses it.

Advantages

You can easily add styles anywhere within your panel contents. This keeps them local to where you use them, making them easier to create. You don't have to maintain a separate style sheet.

Disadvantages

You don't maintain a separate style sheet. So, now your style definitions get scattered around in various panels in a disorganized way. The argument could be made that this also makes it difficult for you to make global changes or for others to change skins, because your local style definitions will take precedence. (Of course, the GUI allows you to modify any face instance with an options block anyway, so you can still make local variations.)

My Opinion

I think we should leave it out for now, then see if we feel under "pressure" to add it. If not, it can stay out.

19 Comments

Comments:

Brian Hawley
22-Sep-2008 18:55:55 Having read and worked on VID2 code and web sites, I would prefer separate style sheets. It increases maintainability. Keep the form/function distinction whenever you can, and it will be easier to have theme designers too.
Let's not add this unless it proves to be necessary.
DideC
23-Sep-2008 3:21 I often use 'style to make a small change to a globally define style created by 'stylize. Ie. I define a global 'label style with right indent and a width of 80 pixels, to be used before fields in a form. But in some forms the label texts are larger or smaller than the 80p availables. So I use stylize to define a 'lab120 or a 'lab50 that is just a 'label with a width of 120 or 50p.
As I don"t know if VID3 will still use pixel adjustment or not (like Gabriele's one does), I don't really know if this feature will be missing to me or not.
So, as you said, let's go without it for now and we will see if it's really needed later.
Karim El Founas
23-Sep-2008 5:03:36 I like the embedded style definitions in panels because I think that some developer want write panels content at different places (in different files) and then merge/include them in one VID3 script.
Typically some panels visually simple can hide very complex code that is more easily maintained if well separated from main script (Font selector, Color selector...)
Brian Hawley
23-Sep-2008 13:55:36 Karim, the styles are not the content. In theory, the content and functionality of a panel will be separate from its appearance. That way a developer can define the content of panels in different locations or files and still maintain a consistent appearance within the application.
This would be the main difference from VID2, where the appearance and functionality of a control were both defined in the style. This was the main thing that made VID2 GUIs so difficult to write, and even more difficult to make look good.
Brian Hawley
23-Sep-2008 14:26:43 The closest equivalent to this feature in HTML/CSS is the style attribute of HTML elements. Having developed complex web sites, I would have to say that the style attribute was a bad choice. Simply by being there, it tends to get used much of the time. And any time it gets used, it makes the overall appearance and layout fragile. You end up with appearance code strewn throughout your generating procedures, making any change to the appearance extremely difficult to make.
It is much better to keep the acts of programming (or content creation) and designing (creating the appearance) separate, as it makes it easier to do both. It allows you to make a graphical tool to do style creation that doesn't have to analyze your program code for exceptions. It allows you to generate the content without getting bogged down in appearance tweaking. It makes it easier to make changes to either content or appearance later on.
I think that we should not implement panel-scoped styles for now. At the very least it will help us debug the design of the style system. This way, any time that we find ourselves wanting local styles, we can ask ourselves what it is that we are really missing. Some of the time it will be application functionality that has snuck into the the style system; application functionality does not belong in the style system and should be removed. Other times it will be a sign that you are getting your form and content mixed up; time to rethink. A good diagnostic tool either way.
Logan
23-Sep-2008 15:13:57 Brian, problem there. If building styles is the only way to perform reusable components, we can not limit styles to have design properties only.
imho, there should not exist distinction between definition of styles and other components. They all have a collection of properties and functions. Some are rendered (call them facets), other stay as abstract definition (call them styles).
the need to distinct design component and functionnal component should stay a decision of the application architect (me and you) but not a coercion of the language.

Brian Hawley
23-Sep-2008 16:49:52 I am not sure of Carl's current terminology (the subject of a later blog), so I will for comments to this post use terminology from different GUI systems.
Carl has made it clear that the display aspects of a control will be defined separately from the behavioral aspects, but that both will be reusable. You need not worry there.
One thing that you need to realize is that the design of a system requires that you make choices. If you are making an application framework, you will need to make some of those choices - if you don't, you are not making an application framework. The whole point of an application framework is to make application development easier, and the way that this is done is to design a foundation on which it will be easy to build. You have done your design well if the developer doesn't need to remake your design to implement their application.
If the developer wishes to make a completely different class of application than the class that the framework is designed to enable, they should probably use a different framework. Fortunately we still have the low-level graphics model and the rest of the REBOL goodies, so we can design different frameworks if we like.
None of this is coerced by the language. You would be shocked to discover how little the REBOL language coerces you to do anything - even the procedural dialect is optional.
Shadwolf
23-Sep-2008 20:21:35 style should be external from panel [] this way all panel can use same styles base and that shorten the code
pannel-styles[ example: style 'parent-style [spec goes here] ... ]
p1: pannel [ example "here it is" ]
p2: panel [ example "there it was" ] and that give a system like CSS for HTML ...
Shadwolf
23-Sep-2008 20:32:57 But I agree that system in a hudge number of page with lot of content can be problematic. But in that cas you can split your code 1 file for the style and 1 file per panel sharing the styles file betwin the panels files.
Or even better once loaded the styles became global and then no need to lead it in each and everyone of the styles styles files.
Anton Rolls
24-Sep-2008 1:19:07 I like the feature that panels can have style definitions directly in them, and I will miss this ability if it is not there. It is extremely handy to start with simple experiments in the context where you are working, then, if it holds water, gradually migrate it to a more "standard" style definition supporting all required aspects of a style. If we are forced to go straight to the style definition every time, that will tend to kill innovation by quick experiments. That's one of the things I love about rebol: how you can move from
do [...] f: does [ ... ] f: has [ ... ][ ... ] f: func [ ... ] [ ... ]
and in the same way with styles and stylizing:
layout [ box ... ] to layout [ style my-box box ... my-box] to my-box-style: stylize [ my-box: box ... ] layout [styles my-box-style my-box] to stylize/master [ my-box: box ... ] layout [my-box]
Anton Rolls
24-Sep-2008 1:24:25 A side note: Doesn't it look strange to do this?
panel [ example: style 'parent-style ... example: example ]
I would prefer:
panel [ style example 'parent-style ... example: example ]
Hmm... maybe they both look strange ! I am probably just so accustomed to R2 VID.
-pekr-
24-Sep-2008 5:23:33 There is something to Anton's words. I too remember quick experimenting with R2 VID and its styling or style overriding. Most of the time it was for the text and fields. That is on plus side.
Now on to minus side:
1) Most of the time I was lazy to move my restyled styles to outer style-sheet, so global stylesheet tweaking would not be so much possible.
2) Inline styles will make it more difficult in overally "play" with central stylesheet and look how your app is changing. You will have to dig into your source code to find out, why some UI section widgets are not affected by our tweaks to central stylesheet.
Ashley
24-Sep-2008 8:35:47 I think the console argument is a moot point when it comes to prototyping multi-line layouts (i.e. one tends to put the code in a script so it doesn't matter whether the style is defined in the layout block or the stylize block).
Paul LYS
24-Sep-2008 14:51:33 Carl said:"I think we should leave it out for now, then see if we feel under "pressure" to add it. If not, it can stay out."; but in my view if it's not implemented now, it would be never. In the contrary we should add it and throw it if no use. To generalize that idea, why don't maintain a special flavour of rebol. We call it "Dirty and Heavy Rebol", it would contained all of stuff. Then a statistical study of the features most used should safely guide the choice of implementation in the official versions of rebol.
P Nongrata
24-Sep-2008 15:43:43 As for "dirty and heavy rebol", I suggest using the proposed browser feature to build-in all manner of documentation for REBOL, perhaps incorporating wiki features. That would bulk up REBOL quite a bit, but it would make the executable much friendlier for new users. If users want fast, ultra-lightweight REBOL, purchase the SDK and custom package your scripts to jettison any baggage you don't need.
Paul LYS
25-Sep-2008 15:23:11 This "DiHeRe" (Dirty Heavy Rebol) could be an opening to free software without competing with Rebol. In one hand there would be a racy REBOL, coherent,efficient and in other hand "DiHeRe" less racy, but full of features (more or less useful) that would provide the opportunity to test if there is no commercial purpose.
Paul LYS
26-Sep-2008 7:17:05 Setting a style on the fly during the description of a window is so rebolish!!!
shadwolf
27-Sep-2008 20:08:24 In general when we design a software involving several "pages" (ex layou, new panel, well windows) you try to set their graphical qualities into a similar look and feel. Same colors applyed in same area same kind of buttons etc... To not loose the attention of the user and keep it focused on what he is doing. That's the same process in HTML. To not have to set up same styles to all the panels u are going to use it's normal i think to have them globalised like CSS in HTML.
But but but becarefull inrebol we have 2 level of styles the first one in VID2 was inbeded into a layout and the stylize who is external. The first one allow fast and quick setting of widgets. The second one allow to heavy redesign (hack) an existing widget.
I think the same way we have global heavy redesigning possibility (stylize) for faces (widgets) we should have a global way to do inline customisation of existing faces. To get a clean source code less code in panel blocks and less redudencies in code. Actually is I have 10 layout and 20 tiles the same embeded styles and i want to modify them (for example lets go creazy to show the user a major version change allowing I'm to differnece the previous version from the new one I have to modify 10X20 lines 200 lines. If that's globalised I only need to modify 20 lines.
Scot
3-Jan-2009 0:56:02 I use local styles until I've decided what I want to keep, then I put it in a "sheet." I would hate to lose this functionality. My development under REBOL has become very organic in the sense that I changes constantly even when it is already deployed. Localized styles make this possible. During one development job I actually automated the transfer of a local style to a sheet. I would hate for REBOL to become more structured. I quite often simply "start over" after I've done a bunch of things in different places and I get a new idea about how things could be designed better, something I would never even consider doing in other languages.