Menu
▾
▴
rapidqnet-develop
|
From: Brian C. B. <Br...@Br...> - 2003-07-17 22:00:57
|
Hi all (extended form of Taj ;-), I was thinking about how the GUI of a program can really impact its success/failure. Looking at the GUI for rq.net, it seems to be lacking quite a bit. So I was thinking that perhaps a wizard like GUI might be nice. 1st Page: A general welcome to the RapidQ.NET program with a little about it and how to use it and of course, Taj's logo (don't you like me refering to you in the third person?). Can be disabled for future launches (with something like a 'Don't show this page again' checkbox). Any 'setup' can be done here. 2nd Page: Page to select the file to compile. "Next (Options)" button might lead to 3rd page, while "Finish (Compile)" might lead to 4th page. 3rd Page (optional): Options page where you can specify the language to compile to, and other options. 4th Page: Compile page where the file is compiled (with progress bar) if need be, select the path to the compiler. 5th Page: Finish - you get compile results and can either go back to step 2 (if your program had errors) or exit. So this could be as long as a 5 step program (Welcome, Select File, Set Options, Watch Compile, and View Output) or as short as a 3 steps (select file, watch compile, and view output). What do you think? Sincerely, Brian C. Becker @ www.BrianCBecker.com Shall we accept good from God, and not trouble? |
|
From: Brian C. B. <Bri...@sh...> - 2003-07-19 01:44:28
|
Reposting: Hi all (extended form of Taj ;-), I was thinking about how the GUI of a program can really impact its success/failure. Looking at the GUI for rq.net, it seems to be lacking quite a bit. So I was thinking that perhaps a wizard like GUI might be nice. 1st Page: A general welcome to the RapidQ.NET program with a little about it and how to use it and of course, Taj's logo (don't you like me refering to you in the third person?). Can be disabled for future launches (with something like a 'Don't show this page again' checkbox). Any 'setup' can be done here. 2nd Page: Page to select the file to compile. "Next (Options)" button might lead to 3rd page, while "Finish (Compile)" might lead to 4th page. 3rd Page (optional): Options page where you can specify the language to compile to, and other options. 4th Page: Compile page where the file is compiled (with progress bar) if need be, select the path to the compiler. 5th Page: Finish - you get compile results and can either go back to step 2 (if your program had errors) or exit. So this could be as long as a 5 step program (Welcome, Select File, Set Options, Watch Compile, and View Output) or as short as a 3 steps (select file, watch compile, and view output). What do you think? Sincerely, Brian C. Becker @ www.BrianCBecker.com Shall we accept good from God, and not trouble? |
|
From: Taj M. <tm...@li...> - 2003-07-19 02:18:07
|
Hi All (Brian), >Hi all (extended form of Taj ;-), > =) >I was thinking about how the GUI of a program can really impact its >success/failure. Looking at the GUI for rq.net, it seems to be lacking quite a bit. > Yes, I agree. >So I was thinking that perhaps a wizard like GUI might be nice. > Yes... I think we should have two options that you can set. They would be Wizard Style or Dialog Based. This would be more flexable. >1st Page: A general welcome to the RapidQ.NET program with a little about it and how to use it and of course, Taj's logo (don't you like me refering to you in the third person?). > Naw... ;-) > Can be disabled for future launches (with something like a 'Don't show this page again' checkbox). Any 'setup' can be done here. > >2nd Page: Page to select the file to compile. "Next (Options)" button might >lead to 3rd page, while "Finish (Compile)" might lead to 4th page. > >3rd Page (optional): Options page where you can specify the language to >compile to, and other options. > Hmmmm. Are you thinking of having multipul backends built into the compiler? This seems like it would be pretty difficult. If RQ could generate DLLs, this would be eaiser, but I think that embedding all possible languages would slow it down. >4th Page: Compile page where the file is compiled (with progress bar) if >need be, select the path to the compiler. > Sounds good. >5th Page: Finish - you get compile results and can either go back to step 2 >(if your program had errors) or exit. > >So this could be as long as a 5 step program (Welcome, Select File, Set >Options, Watch Compile, and View Output) or as short as a 3 steps (select >file, watch compile, and view output). > >What do you think? > Sounds good to me. Give the user all the options. --Taj -- "My software never has bugs, it just develops random features." |
|
From: Brian C. B. <Bri...@sh...> - 2003-07-20 11:37:01
|
Hi Taj, > Hmmmm. Are you thinking of having multipul backends built into the > compiler? This seems like it would be pretty difficult. If RQ could > generate DLLs, this would be eaiser, but I think that embedding all > possible languages would slow it down. Yes, I'm still trying to figure that out. I haven't found a good solution, but I do think that having all the backends in the compiler is good so the user can download one compiler (with only one runtime). What we could try to cobble up byte code with the RapidQ DLL. But still, I can't see exactly how that would work. > Sounds good to me. Give the user all the options. Yes, that was the idea. Sincerely, Brian C. Becker @ www.BrianCBecker.com Shall we accept good from God, and not trouble? |
|
From: Taj M. <tm...@li...> - 2003-07-20 14:56:50
|
Hi Brian, > Yes, I'm still trying to figure that out. I haven't found a good solution, > >but I do think that having all the backends in the compiler is good so the >user can download one compiler (with only one runtime). > >What we could try to cobble up byte code with the RapidQ DLL. But still, I >can't see exactly how that would work. > Me neither. We could write the backends in another language (eg, C++, C#, Pascal, or KoolB) and then call them in RQ.NET--although this would be hard and be a pain. Need to go, Taj -- "My software never has bugs, it just develops random features." |
|
From: Brian C. B. <Bri...@sh...> - 2003-07-21 11:23:00
|
Hi Taj, > Me neither. We could write the backends in another language (eg, C++, > C#, Pascal, or KoolB) and then call them in RQ.NET--although this would > be hard and be a pain. That's one solution. But I think that when RQ.NET can compile itself, then the backends can be separated off into there own DLLs. So perhaps we just create an object for each backend: CSharpBackend CppBackend AsmBackend PascalBackend To bad RapidQ didn't have polymorphism or we could just have one 'father' class that all other backends were derived from and then select the actual backend at runtime. Something else that may work is function pointers. Store all the functions for a backend in an array, and then select the array on runtime. We'll think of something. Sincerely, Brian C. Becker @ www.BrianCBecker.com Shall we accept good from God, and not trouble? |
|
From: Taj M. <tm...@li...> - 2003-07-21 14:47:23
|
Hi Brian, > That's one solution. But I think that when RQ.NET can compile itself, then > >the backends can be separated off into there own DLLs. > Right. >So perhaps we just create an object for each backend: > >CSharpBackend >CppBackend >AsmBackend >PascalBackend > True, but then we have to check every time what the user wanted, and then call the correct backend... It could work, though. >To bad RapidQ didn't have polymorphism or we could just have one 'father' >class that all other backends were derived from and then select the actual backend at runtime. > True. That would be nice. >Something else that may work is function pointers. Store all the functions for a backend in an array, and then select the array on runtime. > You can store functions in an array? That might work a little better, but still be messy... --Taj -- "My software never has bugs, it just develops random features." |
