Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General Discussion » View Thread |
Messages 1 to 4 of 4 total |
Theme pre-processor |
Mon, Sep 21 2015 4:24 AM | Permanent Link |
Matthew Jones | I'm posting this because I suspect others may have similar ideas. And
because I don't think it is viable, but the discussion is interesting anyway. I'm working on converting my web shop, and loving the new layout engine. But I will want to tweak the theme that is the default, and I am waiting for the next update to reduce the work needed to repeat my changes. That made me think of this idea: Theme pre-processor: The theme files should have a macro-type substitute rather than hard coded colors or border widths, etc. This would allow someone to change the text color, or button color, or size, or whatever, just by changing the definition of "THEME_TEXT_COLOR" in the definitions file. Like it blue? Make the value blue, it all changes. Magic, and ideal. So then you take it to its conclusion - there is the button text color, tab text color, label text color. Me, I want them different. You want them the same. So that means that *every* property needs to be a definition, otherwise it can't work properly. One person might set them all to THEME_TEXT_COLOR to make them the same (which then requires multiple passes for each line until no more substitutions). Okay, done that, but how does the IDE editor look now? I can either put in a width of 4, or it could be BUTTON_WIDTH. Tim would have to make all that work. And you know what? You really ended up with what you have now - a system where a new property is added or changed, and you have to update the your custom file from the standard file again. Which is why I think that the whole idea is daft, once extended to make it work. But, that brings us back to the problem we face today. We take a copy of the theme (or part thereof), and edit it. Then EWB is updated to have a new property, or a change, or something, and we need to take that across and apply it to our theme, or apply our theme changes to the master again. This needs to be a repeatable and clearly defined process with a tool to help. I know Tim has been pondering it, but he has other fish to fry more productively. Is there a tool that we can buy today to solve this? Or would it be easy to knock something up in Delphi to do it? What is actually needed? My presumption would be that you need three, perhaps 4 copies of any file. The original that you took, the changed one you are using, and the new one supplied with the IDE. Perhaps the 4th would be the "output" of the process? Except you really want the IDE to work with the output so that you can see it work live. So best to have 3. What is the magic formula needed here? -- Matthew Jones |
Tue, Sep 22 2015 11:40 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Matthew,
<< And you know what? You really ended up with what you have now - a system where a new property is added or changed, and you have to update the your custom file from the standard file again. Which is why I think that the whole idea is daft, once extended to make it work. >> Well, it *would* work, if everyone simply stuck with what I set up and only want to do things like change colors, font sizes, etc. But, if you started to want to do things like add borders that weren't there before, etc. you start to run into the situation that you're describing. I think what is really needed is a "smart" global interface updater. And by "smart", I mean really smart, as in I have no idea yet how such a thing would work with interfaces that I didn't design. Tim Young Elevate Software www.elevatesoft.com |
Thu, Oct 8 2015 5:18 AM | Permanent Link |
Christian Kaufmann | I was playing arround with interfaces and multiple states and I think, finally I understand the
concept. It's really very flexibel, sometimes to flexibel. And I came up with exactly the same idea: Makro constants for .wbi files. For an application I think you need: - one font name - about three font sizes (small, normal, large) - about five colors, maybe more with backgrounds. - one set of padding/margins/border for all controls. All these constants could be in one file and like this I don't have to change all .wbi files just because I want to use a different font(name). The problem with copies of .wbi files remains, but I need much less copies. Another thing that could help would be to move the component library path to project options and to rebuild the component library everytime you open a project. And finally I'm not sure, if ApplyProperties has to be different for all states or if it would be better to move that on top level. Of course there may be cases, where this flexibility is usefull. But normally if I change the background in "Hot" state, I want to change it when going back to "Normal" as well. cu Christian |
Fri, Oct 9 2015 12:28 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Christian,
<< I was playing arround with interfaces and multiple states and I think, finally I understand the concept. It's really very flexibel, sometimes to flexibel. >> Yeah, it's too flexible, IMO. << Another thing that could help would be to move the component library path to project options and to rebuild the component library everytime you open a project. >> It's actually not necessary to do this, but I do need to add some code to the component library/designers to refresh the interfaces when a project is loaded. In upcoming minor releases, two things are going to change: 1) The way interface customizations are handled (this topic) 2) The way databases/datasets are handled Both are going to become more project-centric, and be much easier to deal with. << And finally I'm not sure, if ApplyProperties has to be different for all states or if it would be better to move that on top level. Of course there may be cases, where this flexibility is usefull. But normally if I change the background in "Hot" state, I want to change it when going back to "Normal" as well. >> I'll have to audit the interfaces for this, but my initial reaction is that you're correct. Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |