[openbeos] Re: scheduler/reminder

  • From: Scott Mansfield <thephantom@xxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Sun, 21 Sep 2003 09:45:23 -0700

Hi Adi,

On Sunday, Sep 21, 2003, at 08:00 America/Los_Angeles, Adi Oanca wrote:

From: "Scott Mansfield"
Huh?  How is comparing GNOME and KDE relevant to our project?  Did I
miss something here?

Maybe lots of articles? :-)

Guilty as charged! :-)


Forgive my impudence but that's like the proverbial "Apples and
Oranges" comparison.  KDE and GNOME: each of these OSS projects strive
towards achieving a common goal in their own way.

True! GNOME by simplicity, KDE by feature availability!

Well said.


IM[not so]HO these
projects attempt to clone the 'doze "experience" in their own
interpretation of same.

Hmm... doesn't OBOS or Linux or Windows or Solaris tries to do the same
thing? A OS...

Not necessarily, no. What I should have said is that if one looks at how the GUI presents itself to interact with the user it's strikingly similar to windows. KDE and Gnome want to draw the user to the "Linux on the Desktop Nirvana," and I feel that they try to achieve this goal by cloning the windoze "experience" rather than invent new ways of doing things. I am of the opinion (and I have lot of them in case you hadn't noticed ;-) ) that we (in general) need a refresh in the whole GUI universe. I'd MUCH rather see a user-centric operating environment than a computer-centric one. Enlightenment, before Raster started the 0.17 branch, was a great step in this direction.


OBOS? It's about empowerment.

Right! By simplicity!

And not dumbing down the interface (*cough* Windows XP *cough*) at the expense of the power user. BeOS has a really good balance -- the best IMHO, even better than my beloved Mac OS X.


Correct me if I'm wrong here and PLEASE PLEASE PLEASE don't be shy
about it.

Generally speaking from a LONG-time experience as an embedded
U*ix/Linux/OSS and recent initiate to OBOS developer:  I can carry out
whatever tasks I see fit within any "Desktop's" sandbox that are at my
disposal.  I don't give a large rodent's posterior about what's
different in the execution, as long as the the end results are
consistent.  Give me a pointy-clicky thing that I can grok and a large
black window with readable monochrome-green text to type stuff in to
and I'll crank out code till the end of time, so to speak -- IOW: I'm
one happy developer.

:-))) Do you think a user cares about that!? I think Linux is your environment! BeOS is to gentile for you...

I *am* a user, and I *do* care about that. I consider myself fortunate that I'm a Linux developer, there's no shame in that. FWIW I use Linux in two places: 1) at work, and 2) here at home as my firewall/NAT/DMZ. Other than that my PC has BeOS as a default boot, with 2000 for the occasional times I need to be MS-compatible (mostly Word stuff). [zzzziipp, dons asbestos suit] The computer I use for day-to-day things (when I'm not developing OBOS) is a Mac with OS X [zzziiipp, doffs asbestos suit].


BTW, you like gdb more than DDD, don't you? :-)

LMAO! Good observation. :-) I don't use either, though. It's printf()'s and assert()'s for me baby! That's my debugging tool!


Carrying this metaphor to conclusion, we shouldn't try to constrain our
customers to what we as a group perceive as the "Best Way" to do things
-- something that I feel you seek to attain by restricting our
customer's tasks by abstraction through a GUI.

If you don't, users will get confused! A balance MUST be found between
usability and availability.
For a CLI geek that you are, I not surprised you think that way. I bet
you love dot files! :-) Users don't!

Ugh, I can't stand dot files. Filesystem warts.


If you have a look at the Terminal,
you'll see many things have a CLI counterpart, even the CD
player. (hint: /bin/play)

Does Windows have such a thing?

Yes windoze does. Please pardon me, I feel dirty for even the
slightest M$ advocation here, but one can launch any 'doze program from
the CLI. [Ugh. Feel dirty. Must shower now. *shudder*]

Really? I didn't know about that! Can you please give me the path to
that file!?

Depending on what version you're running it either referred to as the "MS-Dos Prompt" or the "Command Prompt" on the Start Menu. For non-NT versions of windows it just opens up a copy of command.com, and for NT versions (NT, 2000, XP), it opens up WINNT\system32\cmd.exe. From there you can launch any kind of program (DOS, console, or GUI).


Then again, there's always cygwin if you just gotta have that unix-like goodness on your windows box. ;-)

Regarding Microsoft... beside their monopoly policy... they did lots of
good things.

Yes, they did. They still do in their own way when they're not stealing 20-year old technology and re-branding it as a Microsoft "innovation," (think "Cleartype"). Personal computing would have been a whole different world without some of the research and standards-making, incidental or direct, they've brought into being.


It's also about scripting...

Yeah, for lazy programmers! :-)

Playing the devil's advocate here...


Hey!  Wait a minute!!!  I make my living by making other programmer's
jobs easier.  What's wrong with using a script to carry out a
repetitive, complex task?

Nothing, really! ... if you use special scripting support like BeAPI
offers.
But if you use a background session to carry out operations through CLI
apps, THEN I can say that what you do is a POOR/CHEAP product, and more... a
lazy programmer.
That can be done, and work real nice... but I DON'T want to see that in
OBOS!!!
I see in BeOS, a remarkable design, made from scratch, and for that I
LOVE IT; it's NOT like Linux where a lots of apps are built one above other.
...remember the discussion we had 2-3 weeks ago about making the GUI
nicer! We all agreed that for making a thing for OBOS you must do it the
right way!


OBOS is will be USER friendly, NOT geek friendly!

Actually I think it will be both. I'm a geek, I love BeOS, I see great potential for OBOS and I'm doing my small part to make that a reality by contributing.


Speaking of that, has anyone heard from Andrew Genduso? We were divvying up work to finish the screensaver kit and *poof* he disappeared. No responses to my e-mails for nearly a month now.

Is reproducibility cast to the four winds?
WTF?  Do you run 'jam' and parse its output from a GUI app during your
course as an OBOS developer?  A script has the potential of being
easily digestible and maintainable in a clear-text kind of way.  FWIW:
"Lazy" programmers don't survive long in the field before they're
called to task and subsequently terminated; M$ employees
notwithstanding.

Hey! That's what I don't like about some people. You say something, and
then one comes and digest all meanings of that phrase.
How the hell could I be referring to complex tasks like compilers!?
I was talking about GENERAL apps! Do you consider good a OBOS program
that uses:
"ls -l | grep xxxx"
to find some files via a criteria, or use PERL regular expressions
support, etc.

My apologies for seeming so brusque here, wasn't my intention. In retrospect I don't know what the heck I was trying to say in that paragraph. Sorry 'bout that.


I consider this POOR programming. If you want to do one thing right you
might want to search the net for a, possibly free, library that supports
easy manipulation of strings or one that works very nice with regular
expressions! That's a good product; a product that comes with incorporated
features, not relying on outside help.


A *smart* developer uses the best tools at her/his disposal to carry
out said dev's final objective in the most efficient, reproducible
manner possible without prejudice to the vehicle used to reach the
finished product.

I *totally* agree! But, if one's "most efficient, reproducible manner"
is scripting with CLI apps, then... he's not "A *smart* developer ".

I see that we disagree on this. Kind of like the whole "vi vs. emacs" thing. :-) FWIW I am a smart developer, at least I'd like to think so. :-) I use the CLI a lot, and use various GUI apps a lot more than the CLI. Again, it's about choosing the best tool for the task and reducing the overhead of the process to as near-zero as possible.


To concede to your point, yes, that are some darned good GUI applications out there that can be used for development purposes. For example, I use Apple's Project Builder for developing OS X code here at home. It's absolutely wonderful, I've never had to get near a command line while developing on said platform and I'm grateful for that.

However, one of my jobs at work is developing and maintaining an embedded GNU/Linux operating system (including porting the kernel to a then-unsupported host processor, the Motorola 8240; something that just cannot be done with a GUI app). This involves building a lot of disparate packages (kernel, libraries, tools, networking, et cetera). It's not enough to just build these packages, but they must also be integration tested to make sure that they play nice with each other. There isn't a GUI app available that allows me to carry out these tasks with consistent, reproducible results. So, with about 500 or so lines of Perl scripting goodness I can fire off a build, goof off for a couple of hours, and see the results of what happened. I'll either have a complete OS ready for flashing or detailed results of what failed and why.

I think where we have our disconnect is that we are looking at different problems from different viewpoints. After reading your responses I think I see your point. You are looking at things from the perspective of the user, and I from a developer's viewpoint, no? (Sorry that one took so long to sink in, I've got a thick skull). If my customer is an end user and I'm providing an application, I'd never give them a finished product that requires invocation of command-line voodoo, that's just way too 1980's DOS-like. Your are absolutely 100% correct, the CLI is totally wrong for this purpose. Given the choice of /bin/cdplay or a nice GUI app, well ... there really isn't a choice.

Adi.

Cheers, Scott


Other related posts: