70 replies to this topic

[patpat]

it seems these days the strategy for the future of the project (winbuilder) has been laid out (it smells Java).
The current version coded in Delphi is definitely showing its age and limitations.

Even when Wimbuilder is a closed source project with a single owner it uses a huge amount of
non-remunerated effort coming from this community, then instead of taking completely unconsulted
architectural decisions why don’t at least ask the comunity users/script developers/etc what they think about the future.

If interested and you are an user just write about what you think of the current wimbuilder, what has to be
added, what has to be improved, what is redundant, what do you guys think about winbuilder competitors,
how you guys see this project from now in 5 years, etc..

If interested and you are a developer you can go further adding ideas about coding platforms, scripting languages,
script file formats, If it's really needed a winbuilder running on a cell phone or in the uProcessor of our microwave,
and things like that,etc…

This could be an interesting thread to come back in one or two years and see how things finally turned out.

Best,
Pat

[pscEx]

I like the ironic way how you hit the middle of the issue, especially

If it's really needed a winbuilder running on a cell phone or in the uProcessor of our microwave,
and things like that,etc…

On the first view I technically do not see any point where I contradict you.

The currently used Delphi7 is really not "current", but "Ice-Age". It is very difficult and sometimes not possible to use unicode wide strings.

But I have the same feeling like you about Java.
I have no idea, why Nuno decided for Java, but I'm sure that his considerations have been made carefully.

I personally do not like Java. IMO to make a product runnable on different platforms, one can compile the product for the different platforms.
Just to tell it here: IMO also a change to C# would be terribly. I hate the framework (Inspite as free lancer I had to do several programming work using framework).

My opinion points to C++.

But Nuno as "father" of Winbuilder decides.

Peter

EDIT:
BTW: I also had to program in Java, because "the whole world" needed Java.
Java is as necessary as upgrading a running XP host to Win7.

[MedEvil]

Too bad! I first thought, that you wanted to create a better WinBuilder. But it's just another pointless topic, where people can write what they want and then get ignored.

We had a whole bunch of these over the years. Look them up, if you don't want to wait 2 years to see what didn't happen.

Though each Winbuilder version is perfectly incompatible with the one before, non of the old design flaws get ever fixed, only a endless stream of features, which are as pointless as they seem to be cool, gets added.

[MedEvil]

@psc
Since you have intimate knowledge of Winbuilder and consider C++ a better suited language, not to mention that you are the main developer. Have you ever thought, if it might not be such a bad idea, to create a own "WinBuilder"? An alternative to the official one?

With all the things we learned over the years, we should be able to avoid some stupidities of the past this time.

[Wonko the Sane]

With all the things we learned over the years, we should be able to avoid some stupidities of the past this time.

Naah, most involved peeps are still in DENIAL mode, it's a looong way to get to ACCEPTANCE:
http://grief.com/the...tages-of-grief/

I still think that the "environment" is of a trifling importance, it is the usage paradigm/structure that could do with a massive overhaul.


Wonko

[pscEx]

Have you ever thought, if it might not be such a bad idea, to create a own "WinBuilder"? An alternative to the official one?
With all the things we learned over the years, we should be able to avoid some stupidities of the past this time.

No. Nuno is a friend of mine, and he trusts me. I'm one of two persons he gave the access to the source code. And I would never think about "my own WinBuilder".

Peter

[Wonko the Sane]

Something that I found at the time of the original great poll:
http://reboot.pro/3755/
was that every other peep wanted to put his/her hands on the builder itself but completely failed to provide any constructive ideas, which BTW - in the few cases when this happened has often been rejected (no matter whether righteously or wrongly) by the main developers.
As soon as this topic is hit, strangely enough some kind of flame war starts .


Wonko

[pscEx]

..., it's a looong way to get to ACCEPTANCE:
Wonko

There are three different groups of users

• I use an app which gives me the result I want to have. To get that result, I accept and follw the app's rules.
• The app gives me the results I want to have. But I do not like design, logic, syntax, etc.
• The app does not give me the result I want to have. I'll forget it.

Peter

[pscEx]

Something that I found at the time of the original great poll:
http://reboot.pro/3755/
was that every other peep wanted to put his/her hands on the builder itself but completely failed to provide any constructive ideas, which BTW - in the few cases when this happened has often been rejected (no matter whether righteously or wrongly) by the main developers.
As soon as this topic is hit, strangely enough some kind of flame war starts .


Wonko

One closing parenthese missing

Peter

BTW: That is the first time that I have the opinion of intelligent board software.
In my quote, It supresses the open parenthese which does not have the close as partner.

[Wonko the Sane]

There are three different groups of users

There is a fourth one:
The app gives me the results I want to have. But I do not like design, logic, syntax, etc. AND I have a better idea for doing this and that BUT the developers think that "as is" is "good enough" AND/OR that "this other thing" needs to be fixed first (though "this other thing" is either complete nonsense or trivial or a simple style or efficiency matter).

As said elsewhere, it is YEARS that Winbuilder can produce a PE.
This is a fact.
During it's evolution, and thanks to the time and dedication by pscEx (mainly) the app has become a little faster, a little "wider", and possibly even a little "better", but the usage paradigm has remained the same awkward one AND still today if you (meaning the newbie/first time user) want to build a PE, your ONLY option is to use a "pre-set".
IMHO an "user friendly" GUI program that has mind-boggingly complex settings (often misteriously - for the newbie- interconnected) is NOT "user friendly", or at least not "user friendly enough".



Wonko

[MedEvil]

I still think that the "environment" is of a trifling importance, it is the usage paradigm/structure that could do with a massive overhaul.

Could you explain this a bit more?

[MedEvil]

No. Nuno is a friend of mine, and he trusts me. I'm one of two persons he gave the access to the source code. And I would never think about "my own WinBuilder".

Sorry but that's about the dumbest argument i've ever heared.
You're not even creating a fork of Winbuilder. You create a completely different Builder, in a completely different language!
So where do you actually see the point, where you betray Nuno?
In the fact, that you might succeed to create a better builder, than he was able to?

[pscEx]

..., but the usage paradigm has remained the same awkward one AND still today if you (meaning the newbie/first time user) want to build a PE, your ONLY option is to use a "pre-set".
IMHO an "user friendly" GUI program that has mind-boggingly complex settings (often misteriously - for the newbie- interconnected) is NOT "user friendly", or at least not "user friendly enough".

You are well known as author of powerful batches using cmd.com / cmd.exe.
Here the "pre-set" is the *.bat / *.cmd you deliver. Like in WinBuilder scripts, every user can change it according his needs. (Open question in both cases, whether it works after change)

BTW: Did you ever try to discuss with Billy the Door the syntax of cmd.*

Peter

[pscEx]

Sorry but that's about the dumbest argument i've ever heared.

I repeat in my words:

Loyality is dumb

Peter

[pscEx]

If you need to use a WinBuilder clone, have a look here.

Maybe you get a program replacing WinBuilder completelly, before you retire!

Peter

[sbaeder]

For me, the issues are also because we don't separate the tool from the projects when discussing things.

If we as developers were more concerned with the experiance of the end-user (the person who just wants a simple PE), then we could do it using the tools available. Heck, we could write it in machine code (binary), or assembly or any number of languages. Then the issue is how much productivity and "FUN" (since this isn't a for profit venture, FUN - or internal satisfaction / gratification) do we get from developing scripts or projects and making them available for others to use (or contribute to).

So far, I haven't found anything that I really wanted to do that couldn't be done using the tools we have. It's not always easy, or 3-5 lines of code, or something that is "cookie cutter" simple, but to me, that is my "FUN"...figuring it out, making it work, learning, and helping other learn. I didn't care if it was simple to make a PE. The challenge of it was what interested me. But I know that's not everyone's desire.

So for me, I look forward to the future here as we continue to "evolve"...


Scott

[MedEvil]

There are three different groups of users

As usual you overlook the 4th group the one, who doesn't use Winbuilder to create 1 build and then run off, to never be seen again, but the ones, who stays on this board and have to deal with WinBuzilders annoyances on a daily basis.

If i do 1 build every 100 years, it can take a whole day for all i care.
But when i need to do numerous builds a day, during development, then the program needs to work way more efficient.

- Though WB goten faster over the years, it's still miles away from the speed Barts builder delivered.

- Faster encoding and decoding algorythms were found, tests where done then it was decided to stay with the slow.

- Loading the interface of scripts takes ages, when the script have big attachments. Some people have started to 'correct this problem' by putting the interface into a seperate script.
But why replace one stupid solution with another one? When the real problem is, that WB loads the whole script into RAM, instead of just reading the interface section like it should.

- WB stores the settings for the scripts within the scripts!
How dead drunk does on have to be, to come up with this stupid idea in the first place and then even consider it a great one?
This issue alone is the reason, that developers can't simply upload the projects they're working on and why people have to reset options every time they downloaded an update.

- As the rise of the CAPI has proven, WB is rather ill fitted for creating cross project scripts.
This issue should be addressed in WB directly and not by some additional script.

- It was promised ages ago, to allow WB to get extended with own dll.

GUI program that has mind-boggingly complex settings (often misteriously - for the newbie- interconnected) is NOT "user friendly", or at least not "user friendly enough".

I do not agree with you. Every person, who thinks he/she is smart enough to use ??? without rtfm, deserves to be proven wrong!
Eloy should not play with computers, they should wait for our dinner bell!

[MedEvil]

I repeat in my words:
Loyality is dumb

It is dumb to give loyalty as a reason, for not doing something, when doing it, would not betray that loyalty.

But then, you already knew that, or you wouldn't have posted such a brain dead translation.

[pscEx]

As usual you overlook the 4th group the one, who doesn't use Winbuilder to create 1 build and then run off, to never be seen again, but the ones, who stays on this board and have to deal with WinBuzilders annoyances on a daily basis.

When I jump down from a chair with the head in front, and have some headache after that, I can either decide not to try it again, or I can try again and again.
When I decide, to jump again every day, I have my reasons for that and should not send my complains to the chair's producer.

Peter

[MedEvil]

I have to agree. You're way smarter than me, in this case.
I actually believed the lies that are being told here. You know, about this being a community, people wanting to improve things, ...

Years wasted, trying in vain to help others, who didn't wanted help, just said so.

[patpat]

@pscEx
>I have no idea, why Nuno decided for Java, but I'm sure that his considerations have been made carefully.
I do not agree. I think Nuno doesn’t really know what he’s doing. I publically challenge him to finish his Java version of winbuilder.
I also publically challenge him to finish his Java WIM library including compression.

>But Nuno as "father" of Winbuilder decides.
I think the father of the project will see how his "sons" will probably soon lead the pack.

>And I would never think about "my own WinBuilder".
Your loyalty speaks very well of yourself! Fortunately there are a lot of very good coders out there without such obligations to Nuno…

>If you need to use a WinBuilder clone, have a look here.
very funny thread with Nuno saying that wants to sue the world for copying his batcher..



@MedEvil
>Too bad! I first thought, that you wanted to create a better WinBuilder.
You sure I don't? Probably this thread would be a good brainstorming starting point if we stick to the proposed topic.

>We had a whole bunch of these over the years.
Tell me about what kind of proposals and their final outcome

>each Winbuilder version is perfectly incompatible with the one before, non of the old design flaws get ever fixed, only a endless stream of features, which are as pointless as they seem to be cool, gets added.
Are you guys up to producing a semi-professional document with all these things; Something defining a structured skeleton of needs, and the experience of their fulfillment or failure in time?…


> Though WB goten faster over the years, it's still miles away from the speed Barts builder delivered. Faster encoding and decoding algorythms were found, tests where done then it was decided to stay with the slow ...
That's very good info.. I wish we can put all of these together as I said before


@Wonko the Sane
>Naah, most involved peeps are still in DENIAL mode...
I agree, Nuno is the number one of them; His real concern is no more that reboot.pro breaking the line of the 40.000 web sites in Alexa ranking…

>As soon as this topic is hit, strangely enough some kind of flame war starts
That could be true, but it is also true that winbuilder clones are reproducing faster these days... and please do not mention ethical issues; if a product does not deliver some other one will...

>I still think that the "environment" is of a trifling importance, it is the usage paradigm/structure that could do with a massive overhaul.
could you explain this a bit?

>but the usage paradigm has remained the same awkward one AND still today if you (meaning the newbie/first time user) want to build a PE, your ONLY option is to use a "pre-set". IMHO an "user friendly" GUI program that has mind-boggingly complex settings (often misteriously - for the newbie- interconnected) is NOT "user friendly", or at least not "user friendly enough".
This is a valuable input, can you go deeper on this?...


@sbaeder
>For me, the issues are also because we don't separate the tool from the projects when discussing things.
This is clever!

>Then the issue is how much productivity and "FUN" we get from developing scripts…
As a developer I get the FUN when the user sends me an e-mail saying your software is so easy to use I did this and that etc..etc..

[Wonko the Sane]

Could you explain this a bit more?

could you explain this a bit?

Sure .
The use of one program/compiler/language/environment/scripting language/whatever is a "technicality", in the sense that sure there are "faster" or "more convenient" or "more suited" ones than others, but unless the chosen whatever is deeply flawed, the "final result" will anyway be delivered, the only difference possibly being the time needed to do the job and/or the complexity for the .script developer.

The "generic" issue I see is about the usage, if you think a bit about it, *any* program can be "reduced" to an "install-like" usage paradigm: the user is prompted, step by step to make choices until the final "run" button is pushed.
As an example, to create the pseudo-GUI for VDK I used a small app that is a wrapper around batch files designed to be mainly an "installer":
http://wizapp.sourceforge.net/
in it's extreme simplicity (and rudimental functions/look) anyone can use it to make a wrap around a batch file, and as well as demonstrated by the half-@ssed (again rudimental, limited and "narrow scoped") batch builder I originally put together over a weekend for the XPCLI, it is perfectly possible to build *something* through "pure batch".
Obviously Winbuilder is far superior to the above and offers a number of very handy (for the .script developer) functions/tools (though IMHO missing some "constructs" that other scripting languages have).
But to the end user the paradigm is still the same:

• take choices
• execute the program

Now when the project is "very vertical" (i.e. very few choices are given to the end user) and simple and .scripts are well written, everything is OK, you click on the stupid start button and after more or less progress bars and mostly meaningless messages across your screen you get a working build.
As soon as the project gets more "wide" or complex, the number of choices available are far beyond the possible knowledge of *any* end user, and since more often than not they are scattered over any number of .scripts, often poorly named, with meaningless description and with "not evident" connections with other settings in other .scripts, the previously described successful and "easy" experience soon becomes a nightmare.
You press the button and after some seconds/minutes of progress bars across the screen you get either a stop error or a non working build.
More often than not the actual error in the log needs to be interpreted, and even if the end user is able to do that, finding which .script and which particular setting has caused that is often very difficult, and possibly by simply changing that setting you resolve that error BUT create a new one because there is another conficting setting in an another .script (and of course you need to re-attempt a build to find that).
Worse than that is when seemingly "everything is fine" but then the build doesn't boot or however has other issues.
If you think about it there is another commonly used app that has a very similar outcome, which is nlite, typically you remove things (and "things" and their interconnectedness with other "things" is poorly or not documented) and you end up with a removed component that you cannot usually re-add to the build, so you are forced to re-start again from scratch again and again.

The issue is not strictly related to Winbuilder or the way it is coded (or because it uses Delphi instead that C or java or whatever), it is a "general" problem of this whole family of "building apps", as another example I have rarely found a more frustrating experience that attempting to build an XP Embedded, with it's stupid (and often completely wrong) component dependencies.

Surely the current "tree" structure is part of the problem of almost *any* app of this kind, but there must be a way to better "group" priorities, to make "interconnectedness" of a choice more evident, to and to avoid (this in particular is the thing that irritates me the most) going 3/4 or 4/5 or 95% through a build to have the stupid thing halt.

As said over and over in this years, there is a mis-representation of Winbuilder, it is depicted as an "easy" app for the end user, it simply it is not.
Over the years many things bettered (a few got worse) the engine was sped up, overall I presume that the "developer job" has been easened a bit, but still there is no particular "added friendlyness" to the end user, and this has more to do with "quality" of .scripts and "coordination" between them then actual engine issues.

IMHO, and I said this over and over (with no effect whatever), there are possible ways to "lighten" user experience, like pre-processing the settings and lessen "interconnectedness" of .scripts (i.e. making each .script more "independent").

@patpat
With all due respect for you, your work and more than that for your opinions, I believe you can express the latter with some less "aggressivity".




Wonko

[MedEvil]

Wonko, i for one miss an explaination, how you would design a Builder to be a simple one button experience, yet have millions of options.

Cause let's be realistic, the very next day, after we released a project, which, with the click of a single button, builds a perfect PE with everything and only the adding or the not adding of apps remains as options, we would get hammered from people, who want to change ???.

Options increase complexity and complexity increases the required knowledge for operation. That's a fundamental law, which can't be broken.

[Wonko the Sane]

Options increase complexity and complexity increases the required knowledge for operation. That's a fundamental law, which can't be broken.

Sure, but nonetheless the user experience can be bettered, I won't repeat over an over again the same things I proposed (and there are possibly much better solutions to the issue) but hiding behind "but it is a complex app" is another form of DENIAL mode.
My opinion is that there is an implicit lie in the Winbuilder "offer", what is promised is "unlimited power with simplicity" (or if you prefer "one button push") what you actually get is "relative power with complexity AND troublesome correction of problems", i.e. when you push the stupid button you NEVER get what you want at first attempt, in some cases you get it after several attempts, in some cases you get it after having learned the whole stuff and actually modified .scripts.
As I see it, having a one button thing is NOT possible at all (and thus "advertising" Winbuilder as being capable of that is false).
So, once admitted that several tries and a steep learning curve is needed, the attempts should be to lessen the pain of the numberless attempts that one has to go through and make the initial learning curve less steep.


Wonko

[MedEvil]

WB projects are for building ones own OS.
Only very, very dumb people believe, that one can build a OS or a rocket to the moon, without any prior knowledge.

btw. I still like to know, how you want to create a project, with all the options any user could ever want, where people can blindly click around, swap in scripts from whatever source, modify existing scripts and all that, while still getting not only a working OS, but the OS they wanted, in the end.

If you can explain, how to do that, something all my years in IT tell me is impossible, then i create a project like that!