Hi, it looks like you have a very promising product in the works here. I have been using Dreamweaver with WP integration to build unique sites for some clients. The sites are usually 80-90% static page with a little dynamic content. I make them in WP for those clients that want a comprehensive content management option.

The videos are really quite slim and don't give a good overview of the full capabilities (or lack of) that TF may have. I realize that this is the place for presales questions, but there are many times where you won't even know all the questions you need to ask UNTIL you see a comprehensive overview for a product or unless someone else asks a similar question that spawns your own question building phase.

I basically have a few general questions.

1. Will there be a method or palette for creating your own options panel for each respective theme?
2. And currently, are the themes built on standardized code that would allow me to code out my own options panel (as a relatively novice PHP guy)?
3. I understand there are no trial versions, but do you offer a refund if the software is indeed not what I expected or if it simply ends up not suiting my needs?

1. Yes, but this will take "several" rather than "few" weeks.

2. You can add your options panel by editing the theme's functions.php and index.php, single.php etc. files. This would be the same as adding options to a static, option-less theme that you got from wordpress.org for instance

3. You can get a refund within the period Paypal allows. Send a short email to billing AT themeframe.com

Thank you for responding, Flynn. And I came up with a few more questions, mainly about style and updating.

1. If I need to change and edit a theme I create in TF say 2 months after it has been uploaded. Do I just upload certain files like the CSS and page files that were edited. or do I need to reupload the complete package.And is anything lost on the server side that needs to be fixed up after the modified theme is uploaded?

2. Is the style editor capable of creating a header that is fluid, or sits outside the #page div. While maintaining the rest of the content as fixed width within the #page div?

3. Is there anything in TF that would allow me to make rounded corners show up in IE. Maybe some IE hacks or a .JS file that can be visually assigned to work around Internet Explorer's "Let's see how many web designers we can piss off today" policy?

PS...A really comprehensive video detailing the deeper and more robust features of TF would probably ward off some of these questions.

1. To edit a previously created theme you'd import that theme's settings file (which you would have exported earlier). This is a text file containing all the settings

2. Currently not, but this will be doable in a future release, probably the next but one version, along with a redesign of the layout "engine". As a first step, in the next version the table will be replaced with DIV's behaving like a table, with a fallback to actual tables for IE6/7. The header won't be part of a table anymore in the next version so you could (manually, by editing the files) move it outside the layout wrapper and give it its own width.

3. Rounded corners can be created automatically by checking a checkbox in the CSS Inspector: "Create this corners for IE (with Javascript)?"

The videos are kinda outdated, I'll try to make a new one within the next days. I am a bit reluctant to putting too much effort into documentation at this stage as the features/handling of TF are still evolving/changing

Said it before Flynn .. but how about a solid timeschedule for once?

Keep reading that TF is promised to be nearly done for about .. say ..1½ year now.
Last announcement was that it would definitely be finished in april ..
But its not .. and no post .. nothing about a new schedule.

Themes (the theme menu's) created with recent betas look different when editing them in the current release.
and if things keep changing .. the same could happen again with next versions.

Before Im going to use TF more .. I want to be sure that themes will be maintainable,
and that I dont have to redo my themes because they look different in later versions of TF.

TF is now called "release candidate" instead of "beta",
but thats more a cosmetic change
if at this stage the features/handling of TF are still evolving/changing.

Ive asked before .. if you need for example 6 months more ... can you please just say so.
Then people know what to expect ..

The fact it's named Release Candidate simply means that I consider it to be at that stage, based on what I have in mind as a "full-featured" state. It does not mean it is not functional, or crippled in functionality in a way that would make it not usable for production use.

This thread is about option pages and being able to create a rather non-standard layout. I said it's coming. These aren't exactly "basic" features. TF will have them, but not having them right now doesn't make TF not worthy of being called a "Release Candidate" - as far as I am concerned.

Regarding schedules: I don't want to start making overly long schedules just to be sure I don't cross them. I am not sure whether I made completely wrong schedules recently.

Regarding "6 months... just say so": The Release Candidate stage should take a few months now, with 6 months being the max. I definitely want to get out of RC phase and release 1.0 within 2011.

Regarding updates not working with existing themes: This is something that may happen when I implement a new, more flexible layout technique. This will be a great improvement though, and I'll try to keep older themes working as good as possible. While this is undesirable you can still create new themes, or reload old themes in old TF versions. It's not like your being left completely helpless.

Long term you'll be able to load older themes in newer TF versions, to a reasonable extent. The focus will be on providing the ability to create fresh themes for the current WP version.

Semantic debate.

Long story short

In the real world:
- "beta" means: "feature complete"
- "Release Candidate" means: "final product (barring some last minute bugs)"

"Release Candidate" does *NOT* mean:
- you have to add (a lot of) new functionality
- things may or may not break in future releases.
- and does *not* mean you plan for an envisioned some 6 months more of development.

"Ready for production use" is a vague term ..
but should at least mean that people can count on things not breaking ..
As you just posted .. you cant guarantee this wont happen.

Of course people are not left "completely helpless".
They can revert to an older version of TF ..
but that will mean they have to revert to a version that missing functionality (thus pre-beta).


You're a talented and nice guy ..
I appreciate all the countless hours you have spent for free on Atahualpa
I think TF has potential and is priced very fairly too ..
thats all not the point.

but here you're throwing in your own personal definitions.
Which makes this derail more into a semantic debate.

Bottom line .. I think its fair to say that TF is still under heavy developtment,
and not ready for production use and not in RC state according to generally accepted nomenclature.

Originally Posted by STB

Semantic debate.
"Release Candidate" does *NOT* mean:
- you have to add (a lot of) new functionality
- things may or may not break in future releases.
- and does *not* mean you plan for an envisioned some 6 months more of development.

By this definition software is not allowed to evolve. At some point developers must release a first "final" version (otherwise known as throwing in the towel), knowing full well that (yes, lots of) additional functionality will be added later.

The Chrome browser is a recent example of this: first it was able to browse the web, then it picked up an options inspector, then it picked up extensions support, then it picked up ccs3/html5... and so on. These were not minor functionality changes, they have dramatically changed Chrome since first release. Along the way, some extensions were broken with new Chrome versions, requiring extension code-rewrites. This is all part of the development cycle. I expect the same from ThemeFrame.

Originally Posted by mdmower

By this definition software is not allowed to evolve.

no (there can be a version 1.x or 2.0 of any software)

At some point developers must release a first "final" version (otherwise known as throwing in the towel), knowing full well that (yes, lots of) additional functionality will be added later.

my point is it makes no sense to me to call something RC while its not even feature complete
and while rather large code changes are needed still
and with that i mean "not feature complete for the final version 1.0" in this case

for production use, I must be able to trust that themes wont break in RC4 or RC8 etc. ... or in the final version.

Of course I can understand that for example .. maybe TF 1.x themes may not be compatible with TF 2.x themes .. but that is really not my point here.

I dont want to spend time reworking my themes, or having to keep track in which beta I made which theme .. then reinstall an old beta to work on it. or spend a lot of time to upgrade my theme to be compatible with the latest RC version or final version.

I think for production use it is fair to expect:
- that things just work
- that its guaranteed that themes will not break in version 1.x

The Chrome browser is a recent example of this: first it was able to browse the web, then it picked up an options inspector, then it picked up extensions support, then it picked up ccs3/html5... and so on. These were not minor functionality changes, they have dramatically changed Chrome since first release. Along the way, some extensions were broken with new Chrome versions, requiring extension code-rewrites. This is all part of the development cycle. I expect the same from ThemeFrame.

chrome is pumping out new "versions" about every couple of weeks
and has been criticized for their really rather meaningless version numbering
but wont get into that .. this was not my point to begin with .. and way off topic here

I think you are comparing ThemeFrame to what would be technically possible and to what I mentioned as possible future features rather than what comparable solutions are out there. If you compare it to what is out there TF does not look that bad or unfinished in my opinion.

Some of the most popular premium themes are just themes that you edit manually based on questions and tutorials on their forum.

I did change the goal to something more advanced on the fly, based on the input from users. This did indeed move the "finished" state more into the future. Finished in the sense of "all features implemented, no more features planned". But while getting there you are still able to create themes, with functionality that you do not have elsewhere, such as the CSS inspector.

Err .. Flynn

wasnt "comparing ThemeFrame to what could be technically possible"
wasnt "comparing ThemeFrame to comparable other solutions out there"

I just said .. please release as promised.

I rather have a stable version with less features ..
than more and more features .. and themeframe final being delayed for yet another year

I just want to know where I stand .. as I asked you a year ago.

@flynn: you're doing a good job! let's have a beer!! ;-)
@STB: you're doing a good job, too! thanks for your input! do you know pixologic? zb? release and final or anything - paid software and a lifetime fee-less upgrade ability are always hard on the wanting side...

robert

Hi!

Where do I find this:

"3. Rounded corners can be created automatically by checking a checkbox in the CSS Inspector: "Create this corners for IE (with Javascript)?"

/Karin

This is a Themeframe function.