Keith Warno wrote:
Lotsa talk I see here about all sorts of X stuff, people saying that they're this and that close to switching to Linux as they're desktop environment, etc etc etc.
And everyone using all these fancy window managers, like KDE, etc (guess cuz they're cool and easy -- *point* *click*)
I feel like an outcast using OLVWM. But there's a reason: the box(es) (SuSE 6.2) are used for development. CGI stuff in C/C++ with mysql thrown in. OLVWM isn't a resource hog.
What I'm curious about is what other SuSE users on this list use SuSE for. How many of yas out there use it for development of any sort in a commercial environment? In 9 out of 10 places I see Red Hat being used and that does evil things to my gut. I personally started off w/ Slackware in the early days (1994), tried Red Hat for literally a day, and have been with SuSE -- using it for development -- for nearly two years.
What about you folks? This is an open-ended sort of topic; My intention is not to start a distro war. I'm simply curious to see what ppl are using _SuSE_ for.
I started with RH 5.0 about two years ago, but as a newbie to Linux I didn't get the the software development stage. About 1 1/2 years ago I switched to SuSE 5.3 and have migrated up the version chain every since. I will continue to do so as long as SuSE maintains their high quality and excellent value, to say nothing of 1300+ pacakges that ride along with the distro. I jumped on board KDE when their first beta was released, about the time I switched to SuSE, and will remain with it because it is an excellent product. Concerning development in SuSE, I began using emacs, which includes version control, then switched to xemacs because I prefer to use KDE. But, I missed the nearly WYSIWYG GUI RAD evironment from my Lotus, PB, VB, FP and VFP days. I ran my own consulting business for 15 years and I could never have made a living using emacs to create affordable mom&pop GUI software. (I used AREV to create text based software) I have experiemented with about everything free that I could find. I tried TurboVision for about an hour. It is a clone of the old Borland text-based C tool and if you want to stay in the console mode it is about as good as anything. Then I started trying some of the more economical GUI RADS. I bought CodeForge but, perhaps, too soon. The development package was merely a GUI version of xemacs. The dialog design capability was just like emacs (and "Visual" C++ [an oxymoron if there ever was one], which I subscribed to for a year) and their method of configuring the makefile and their approach runing CVS were too error prone, inflexable and buggy. Through several upgrades they never added GUI dialog ability, so I dropped it. The same for CodeWarrior, and a couple other CodeXXXX packages. I never looked at any more packages unless that were a) economical and b) had GUI dialog capability. Over the years I've paid several thousands of dollars for commerical GUI RAD, and the higher the version number the more expensive they got and the more bloated, buggy and unusable they became. All followed M$s lead in their business model. I tried PGACCESS, which comes with PostgreSQL and is an ACCESS clone to some degree. It uses TCL and is 'nice', but too primative to use for professional development or for very large projects of any kind. The widgets were not visually appealing and lacked sophistication. Every widget was a 'grid' and a real grid wasn't in the tool kit. Sophistication? a) multiple and adjustable look and feels, adequate property settings dialogs (I hate writing long lines of dotted code to set height, width, font properties, tab orders, etc...) b) data-aware capability without writing tons of code for each widget (I know, that one requires a native backend or adjustibility to multiple backends), c) methods that can be accessed and modifed at the widget level and extended by adding UDFs to the widget or dialog form, d) event handling and code modification, e) supports objects and inheritance (this requirement eliminates VB and VB clones - cut&paste is not inheritance..:). I downloaded and tried TCL and Visual TCL. The latter was very nice, and had a good GUI tutorial, but the widgets were no better than TCL and lacked sophistication. GK+ improves a bit but it is still not there. TCL, V-TCL and GK+ make nice tools for making small SDI apps. I tried XForms, another 'nice' but limited tool, just like PGACCESS. I tried Python, which is a very nice OOP language and a great 'glue', (C without memory management woes), but when attached to the above mentioned widgets the sophistication problem comes along for the ride. Then KDevelop released beta 1.1... Heaven! KDevelop (I'll call it KD+) fits hand in glove to KDE. It is like using VB on Win95. (Sorry for the metaphor, but it is true...) KD+ uses C++ and all of it's OOP abilities. KD+ uses the same toolkit that is used to build KDE (hand in glove). KD+ uses 'Signals & Slots' (easy to learn and use, fast and reliable) for component communication, the same as KDE. The Dialog design tool lacks only a couple of things: a) group manipulation ability - select several controls and adjust, say, their position properties, fonts, colors, tab order, etc, at the same time, and b) a few more KDE controls, like true grids, a date control, I don't mean the datecontrol or datepicker, but a textbox with date formating built in. (getting picky ain't I?) There are a few more suggestions and nit-pics but hey, this is only beta 1.1. KD+ has got it all (almost) and will sweep the Linux world like a raging forest fire! My own plans are to use the xbase OOP code and create VFP 6 compatible data-aware widgets, a datawindow and a tcl box. VFP 6 carries too much WinXX baggage to want to mimick it exactly. That's why the DBC is such a dog. But, a group of xbase controls that allow design-time binding to fields in xbase tables, setting indexes, etc..., and a TCl box that allows entry of SQL code which is parsed and executed.... That's the goal, anyway. A fast, light and robust xbase backend to KD+. Anything you would attempt with VFP could be done with KD+. The price is write and you wouldn't have to live with those annoying 'features' that can't be fixed because you don't have the source. So, Keith, that's about it. Jerry -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/