If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#31
|
|||
|
|||
life after Windows....
In article , aracari
wrote: This will include deciding what program functions you want the user to have access to. Those which are not made available through the GUI can often be accessed on the commandline used to start the program. ugh. hidden features are obnoxious. if it's important enough to implement, why hide it from the user? Wise up friend. You're obviously not very well clued. ah, insults. that always bolsters an argument. Many functions are either deliberately hidden because users cannot be trusted to use them properly -or- the programmer leaves them out for reasons of development speed, laziness or whatever. if users can't be trusted to use certain features, why are they even in the app at all? and if the features are hard to use properly then the interface needs to be rethought. you are basically justifying bad ui. A fair number of programs in Windows and also many application programs have functions which are only available via the commandline used to start it. I posted one example in this thread: Here it is again: "C:\Program Files\freepops\freepopsd.exe" -t 6 The additional parm "-t 6" tells freepops that I wish the program to support up to 6 webmail accounts (default = 4). The only place to specify that parm is when the program is started. why is it limited to 4 in the main ui and 6 with a hidden option? if it can support 6 accounts, why not offer that capability to everyone? if 4 is stable and 6 is buggy, then fix the bugs rather than offer it as a hidden option that might crash. There are many other examples of this. Irfanview has got several dozen commandline options which can be used to start it etc. yes, there's plenty. that doesn't mean it's a good thing. |
#32
|
|||
|
|||
life after Windows....
aracari to e-mail me wrote:
'Ray Fischer' wrote this: aracari to e-mail me wrote: 'nospam' wrote this: wrote: the point is that the original mac os did not have a command line. Fine, I have no problem with that. Nevertheless, the GUI will have been created after writing the program function code itself (or normally would be). there's no reason for one to be before the other. it all depends on what the app does and how the developers wish to implement it. The normal cycle is to design the program you want to create and then set about writing/testing it. That is often an iterative process which might take some time. When you've finished and you've got the program doing exactly what you want, you might then create a GUI for it. Hmmm. With a great many commercial applications the UI is an integral part of the program and is included as part of the overall design. Grafting on a UI afterward typically results in crap. It probably depends how well the program is designed and written. You cannot do a proper design without considering the user interface. eg: years ago I did some APL programming and there were two styles for this: APL programming is irrelevant. If that's the limit of your programming experience than you have no basis for your opinions. 1.a huge single program which changed the world in one go but was virtually impossible to further develop or maintain -or- 2.breaking it down into lots of small logical functions, which were then collated by using a new top function which ran all the others. This method was always much easier to maintain. The former is what inexperienced programmers do, the latter is for the professional guys. These days the 2nd approach is what the newbies do. Professional software engineers are a couple of steps beyond that. Exactly the same applies to complex DOS batch files etc. I wrote a large series of 4DOS batch files some years ago which turned my 4DOS system into a 100% menu driven machine and never saw the DOS prompt. I used up to 50 seperate batch files for this to avoid over complexity and ensure easy maintenance. I routinely add thousands of lines of code to systems that have millions of lines of code. This will include deciding what program functions you want the user to have access to. Those which are not made available through the GUI can often be accessed on the commandline used to start the program. But if you don't know what you're going to allow the user to do then how do you know what program functions to develop? At the time of program development you will know ...or you haven't done the design phase thoroughly. Design is part of development. -- Ray Fischer |
#33
|
|||
|
|||
life after Windows....
aracari writes:
Which was one reason for MS creating the GUI: "make it easy" and "make it pretty". They do the same thing with Windows servers. Unfortunately it has more negative effects with servers than with desktops. |
#34
|
|||
|
|||
life after Windows....
aracari to e-mail me wrote:
'Ray Fischer' wrote this: aracari to e-mail me wrote: 'nospam' wrote this: wrote: the point is that the original mac os did not have a command line. Fine, I have no problem with that. Nevertheless, the GUI will have been created after writing the program function code itself (or normally would be). there's no reason for one to be before the other. it all depends on what the app does and how the developers wish to implement it. The normal cycle is to design the program you want to create and then set about writing/testing it. That is often an iterative process which might take some time. When you've finished and you've got the program doing exactly what you want, you might then create a GUI for it. Hmmm. With a great many commercial applications the UI is an integral part of the program and is included as part of the overall design. Grafting on a UI afterward typically results in crap. It probably depends how well the program is designed and written. You cannot do a proper design without considering the user interface. eg: years ago I did some APL programming and there were two styles for this: APL programming is irrelevant. If that's the limit of your programming experience than you have no basis for your opinions. 1.a huge single program which changed the world in one go but was virtually impossible to further develop or maintain -or- 2.breaking it down into lots of small logical functions, which were then collated by using a new top function which ran all the others. This method was always much easier to maintain. The former is what inexperienced programmers do, the latter is for the professional guys. These days the 2nd approach is what the newbies do. Professional software engineers are a couple of steps beyond that. Exactly the same applies to complex DOS batch files etc. I wrote a large series of 4DOS batch files some years ago which turned my 4DOS system into a 100% menu driven machine and never saw the DOS prompt. I used up to 50 seperate batch files for this to avoid over complexity and ensure easy maintenance. I routinely add thousands of lines of code to systems that have millions of lines of code. This will include deciding what program functions you want the user to have access to. Those which are not made available through the GUI can often be accessed on the commandline used to start the program. But if you don't know what you're going to allow the user to do then how do you know what program functions to develop? At the time of program development you will know ...or you haven't done the design phase thoroughly. Design is part of development. -- Ray Fischer -- Ray Fischer |
#35
|
|||
|
|||
life after Windows....
In article , aracari
wrote: Often an undocumented feature is written into a program for use by support staff or for special purposes, not for everyday users. It wouldn't make sense to include them in the GUI for the reason you and others have already stated: "users can't stop fiddling". true, but that doesn't mean it can only be accessed via command line. A fair number of programs in Windows and also many application programs have functions which are only available via the commandline used to start it. I posted one example in this thread: Here it is again: "C:\Program Files\freepops\freepopsd.exe" -t 6 The additional parm "-t 6" tells freepops that I wish the program to support up to 6 webmail accounts (default = 4). The only place to specify that parm is when the program is started. why is it limited to 4 in the main ui and 6 with a hidden option? if it can support 6 accounts, why not offer that capability to everyone? if 4 is stable and 6 is buggy, then fix the bugs rather than offer it as a hidden option that might crash. 1.support for 6 accounts is not buggy. if it's not buggy, why not let everyone benefit from it? 2.the default of 4 isn't even included in the GUI! It just defaults to that number when the program is started. why not offer it directly instead of a hidden option? I cannot say why but... 2a.perhaps the author considered that 4 was ample in the program's first release, but later learned that some people wanted more. He then wrote a quick fix to increase the number to whatever the user wanted, and issued the parm option to achieve it. if that's the case, then he didn't want to take the time to properly revise the software. what else did he skimp on? that does not lend confidence in the product. and it's actually 5, according to the docs: http://www.freepops.org/en/files/html-manual/node5.html 2b.otoh maybe each additonal account consumes system resources and he wanted to limit that in the early days for average users. if it's limited, then why offer the option? and if the limitations are gone, why is the option not in the main ui? My main point was to show that many programs have options which are only available through parms on the start-up commandline, not through the GUI. sure, but that doesn't mean it's a good idea. there are also a lot of programs that have a horrible ui, are slow in execution, use more memory than they need to (or worse, leak) and other flaws. Commandline parms reduce the time necessary to complete the GUI program development without limiting its abilities. in other words, the app is rushed to market and released prematurely? and that's supposed to be a good thing? more importantly, the command line is not a proper api. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
life after Windows.... | White Spirit[_2_] | Air travel | 7 | March 28th, 2009 08:29 AM |
life after Windows.... | Doug Jewell | Air travel | 3 | March 27th, 2009 05:38 PM |
life after Windows.... | Doug Jewell | Air travel | 2 | March 27th, 2009 11:50 AM |
life after Windows.... | Doug Jewell | Air travel | 0 | March 27th, 2009 09:09 AM |