|
|
| Post Number: 1
|
Nick Valric 
Group: Members
Posts: 3
Joined: Apr. 2004
|
 |
Posted on: Jun. 13 2004,10:34 |
|
   |
As far as i can see, ezb files are in binary format. There may be a reason for this but i generally believe that text format is a better and much more user-friendly choice. If binary data are necessary then perhaps the data should be split to two different types of file like: .bin for binary information and .mnu for menu, text and layout information. When the user selects the "Create ISO" button, the data should be merged to a single .ezb file, that is if a binary file is needed at all.
You could use XML which would be the ideal choice but even a simple "old .ini like style" format would be much better than the binary one. Advanced users would then be able to copy-paste code in there, search, edit or replace fragments of text etc. Generally i think that binary data should only be created once the user has clicked the "build iso button".
Someone may ask why i write this stuff. The reason is that Easyboot GUI is still rather weak. You generally shouldn't make things more complicated than needed. And you shouldn't make them different just in order to make them different (you need to have a very good reason for this). Eazyboot breaks the fundamental way that windows GUI operates. Here are some examples:
-If user wants to move something, he should simply click it and drag it. All programs work that way.
-If he wants to resize it, he could simply click the border and drag until the size is the right one.
-Right click should pop a menu of the frequently used commands like "copy", "paste", "align items ->left, top, bottom ", "properties" etc
These are some random examples but there are others which are far more important: You can't multiselect or group items and then perform a specific action: Lets say you want to move 20 items (that already exist) 10 pixels up and 20 pixels right. What do you do?! Or lets say you want to create 10 menu items left aligned with same normal and highlight colors. With the current gui doing something like that is becoming both frustrating and time consuming.
Read again my post. I' m not saying that your program is not good. On the contrary, it is great. And, in fact, it is the only one that can generate interactive graphic menu's for boot media so easily. But menu modification and update is not a trivial procedure with EasyBoot. You should work on improving that too.
with regards
|
 |
|
|
| Post Number: 2
|
Evil Titix
Group: Members
Posts: 10
Joined: Jun. 2004
|
|
Posted on: Jun. 13 2004,13:20 |
|
 |
Well, actually it is far easier to store the data the menu needs inside the code - for booting off a CD involves simply loading a bunch of consecutive sectors at 007C:0000, then running them (this is the "no emulation" way, used by EB).
Of course, using some kind of .ini (or .xml) files is far from being a pain in the ass - it could be done just as easy. But look on the dark side: if EB would be completely .ini-driven, there would be practically no way of keeping up the license: any lamer who gets his hands for 3 minutes on any CD created with EB would be able to extract the code, and therefore able to create as many EB-based CDs as he would please, without paying a cent to EZB Systems. Now, do you think the development would be kept up in that context?
And if you're really pissed off because of the interface, may I suggest reverse engineering? I mean, build yourself a GUI, then simply patch ezboot.ezb accordingly. VC++ (or Delphi, or whatever) + assembler knowledge should be enough.
Then again: if you're not technical enough, then probably you can live with the current way of doing things anyway. Think of this: you don't build a system disk every day, do you? I'm a user of EB for about 2 years, but this far I think I spent more hours on CorelDRAW! creating backgrounds than in EasyBoot itself...
--------------
Mircea Horea IONICA
<mionica@as.ro>
|
|
|
|
| Post Number: 3
|
Nick Valric
Group: Members
Posts: 3
Joined: Apr. 2004
|
|
Posted on: Jun. 19 2004,13:03 |
|
|
| Quote (Evil Titix @ June 13 2004,18:20) |
But look on the dark side: if EB would be completely .ini-driven, there would be practically no way of keeping up the license: any lamer who gets his hands for 3 minutes on any CD created with EB would be able to extract the code, and therefore able to create as many EB-based CDs as he would please, without paying a cent to EZB Systems. Now, do you think the development would be kept up in that context? |
IMHO, reducing the productivity and the capabilities of the software just in order to protect it from "those potential lamers" is a wrong strategy itself. Lamers are everywhere, and the worst is that they will find a solution anyway. Do you really think they will not?? (come on.. i m not the only one who can use an internet browser...)
So, it is simple: If it must not be completely .ini based, then simply don't make it *completely* .ini based. By making it more powerful, more customers will want to buy the application. Think it that way.
| Quote (Evil Titix @ June 13 2004,18:20) |
And if you're really pissed off because of the interface, may I suggest reverse engineering? I mean, build yourself a GUI, then simply patch ezboot.ezb accordingly. VC++ (or Delphi, or whatever) + assembler knowledge should be enough.. |
Hmmz. The fact that i don't have the time to reverse engineer EasyBoot does not mean that i will not express my opinion right? nor does it mean that my opinion is wrong. Even so, if i do ever decide to design a new gui, then that would actually harm EZBSystems rather than doing any good... right?
I believe that this way of thinking is totally wrong. I m only suggesting things that will improve EasyBoot software, and believe me, i ll get no profit out of it. Even if you (they) do implement any of this stuff, most propably i wont be the one who will use them because easyboot is not a tool for my work but ^was^ an alternative solution for a hobby task. I have already spent some time over the keyboard to express some ideas of how to make it more powerful. Think of it as a honest review. EBZ programmers may accept the ideas or reject them. Telling the potential customer to reverse engineering the product is just a bad idea.
I use a combination of diffenent programs like bcdw, miso, nero and X-changecl all coordinated by a custom WSH "wrapper" which automatically recreates and updates all the files i need with some message boxes and command line parameters. So i only have a single bootable and easy updatable dvd. Between that and reverse engineering the .ebz are about 4 months of hard work... just for hobby? no thanks...
|
|
|
|
| Post Number: 4
|
xoben
Group: Super Administrators
Posts: 849
Joined: Nov. 2003
|
|
Posted on: Jun. 19 2004,22:39 |
|
|
Thanks Nick Valric for your sugestions.
Script is good for expert, and both CD Shell and Boot CD Wizard suport it. We will consider to add this feature someday.
|
|
|
|
|
|
|
