Wow! This is the biggest thread I''ve seen in the Unix forum in a while!

Anyways, I''m beginning to get confused. Whenever I throw out new ideas for some cool tool that''d make Linux life easier, I usually get people saying "but that''s not Unix" and other stuff about the Unix Phylosophy of lots of little tools designed to do specific purposes.

But isn''t that opposite of this discussion? Now we want a super awesome UI for stuff? What happened to the Unix Phylosophy and command line tools?

And I''ve tried Glade, and I couldn''t make sense of it. I made a window and added a button and text box to it, then loaded up the project it made in Anjuta, and the thing wouldn''t even compile. That''s real good. I have NO idea how to get it to work.

And GTK! I actually think I like programming Windows better. Windows programming seems to be more object oriented, but GTK is...i dunno. There''s functions coming out of my butt! "g_signal_swap() is like g_signal_blah() except it does this and that" so, uh, what''s the ''swap'' mean?

Could perhaps all this talk about UI also apply to code library interfaces? Could perhaps open source libraries be so hacked to death ("I''m gonna add my function to do this, and I''m gonna call it blahblahmakenosense()!") that learning them is excessivly tough, scaring away potentially good open source programmers?

Anyways, that''s just some of my thoughts.

quote: Original post by BradDaBug
And I''ve tried Glade, and I couldn''t make sense of it. I made a window and added a button and text box to it, then loaded up the project it made in Anjuta, and the thing wouldn''t even compile. That''s real good. I have NO idea how to get it to work.

From The Glade FAQ:

3.1 How do I build the code generated by Glade?You need automake >= 1.4 & autoconf >= 2.13 to build the generated C code.You also need gettext >= 0.10.35 if you enabled gettext support. See the''Requirements'' section in the README file for links to these.Run ''./autogen.sh'' in the toplevel directory of the project to runautomake, autoconf and the related utilities to build the Makefiles. Passit any options you want passed to configure, e.g.	./autogen.sh --prefix /usr/local/gnomeThen run ''make'' to build your application.

quote: Original post by BradDaBug
And GTK! I actually think I like programming Windows better. Windows programming seems to be more object oriented, but GTK is...i dunno. There''s functions coming out of my butt! "g_signal_swap() is like g_signal_blah() except it does this and that" so, uh, what''s the ''swap'' mean?

I think GTK+ makes a much nicer GUI library than the Win32 API, personally. After looking at a ''hello world'' example, all I''ve needed to work with GTK+ is the reference. That object hierarchy demonstrates the object orientation of GTK+ well, too.

quote: Original post by BradDaBug
Ever browsed a CVS server via HTML (one where every identifier was a link to where it was declared and such)? Pretty cool, wasn''t it. What if there was an IDE that did that?

It could use Gecko to render the page! It''d sit there and let you edit the code, then behind the scenes it updates the .cpp file, then generates a new HTML file on the fly.

Maybe it could be integrated into Anjuta. Anjuta is good, but I wish it had virtual folders and stuff. Trying to edit a massive project is really tough.

QT''s new developer studio thing (whatever it is called) can do this. When you move the cursor over a class or method, it will become underlined in blue and you can click on it and the QT docs will be brought up in QT Assistant.

quote: Original post by Prefect
Current-day interfaces definitely aren''t optimal. However, changing the way computers work radically from one way to the other isn''t going to work. Most people are willing to try some minor changes when you talk them into it, but they simply refuse to try something that''s completely different.

No offense, but that''s utter nonsense. People want machines that work and do what we want them to do. If you present a system that is affordable, accessible, efficient and reliable, does what users want and need it to do, is easy to learn and use, and doesn''t invalidate all of their existing experience and work investment - you have a sure-fire hit on your hands.

As corroboration, I point merely to the fact that Windows Longhorn is going to be a radical departure from existing Windows versions (see Question 2).

quote: Let''s face it, simple Makefiles are not powerful enoguh when you want to go full portability, and autotools-based configuration is a mess.

Makefiles are extremely powerful, just neither intuitive nor user-friendly. There''s also the problem that makefiles are designed for command-line tools and CLI invocation, which has made fitting them into IDEs a chore. Add to that the complexity of managing the various entries and logic in make...

quote: What I''d love to see is a system which is as simple to use as projects in MSVC++. Just copying .dsp files is NOT going to work, however, as those are nearly impossible to edit - such a system must be easy to use from the command line, too.

Project workspaces further complicate the issue.

quote: Basically, I''d like a system where I can just say: "Create executable Foo from source files a.cpp, b.cpp, c.cpp; link with library SDL". The system would then figure out (mainly by using file extension / file types) which compilers / linkers to use, and what options to use.

Dependency on filename attributes is another flaw of current GUI systems. Macs have file IDs which identify a file''s contents as being a particular type. The *nixes need to couple Mac-like IDs with inodes/HFS IDs to give the user really powerful, yet easy-to-use, file manipulation abilities.

Besides, if the system is being integrated with the IDE, doesn''t the IDE already define compiler, linker, profiler, etc for use in generating binaries various targets? Why not query the IDE if invoked that way?

[offtopic]
There are also ancillary issues when you consider C++''s outdated compilation model, blindly reproduced by every vendor out there. The #include metaphor is overused and tired as a result. C++ needs (even vendor-specific) packaging, the elimination of function/type forward declaration requirements (which eliminates the need for your own header files) and a multi-pass compilation process. If that is accomplished, it further questions the viability of using name attributes to determine the appropriate bintools to use.
[/offtopic]

A lot of the features found in tools like makefiles and autoconf are superfluous. Take compiler detection. Rather than building little samples, why don''t compilers simply provide an "output compiler specs" switch? Why don''t sysadmins symlink the current compiler to standard filenames (like cc)? A few seconds of config would eliminate several gigaflops of redundant computation that way.

Given the above, a build configuration system need do the following:

• Detect the current platform (query IDE or compiler)


• Determine if compiler can compile given code (query compiler).


• Collate the appropriate source files per platform


• Invoke appropriate bintools.

Pretty straightforward, isn''t it?

quote: Original post by BradDaBug
Anyways, I''m beginning to get confused. Whenever I throw out new ideas for some cool tool that''d make Linux life easier, I usually get people saying "but that''s not Unix" and other stuff about the Unix Philosophy of lots of little tools designed to do specific purposes.

The problem is often not that "that''s not Unix," but that the idea fails to consider the variety of ways in which Unix and it''s various tools are used. You often hear the sentiment "X Windows should be replaced" (which I actually agree with), but few of the most vocal understand X''s design goals and how well it functions within those parameters. In many respects, I merely feel that X should be extended or refactored - steps taken to reduce network traffic between server and client; a desktop environment layer be added as separate from GNOME/KDE/WindowMake/AfterSTEP/whatever that provides a common functionality and thus makes applications for each of these window managers and desktop environments interoperable; and similar improvements.

quote: But isn''t that opposite of this discussion? Now we want a super awesome UI for stuff? What happened to the Unix Philosophy and command line tools?

Command-line tools are not the embodiment of the Unix Philosophy. ls, for example, does more than one thing (why does the list directory contents command do pretty printing, alphabetical sorting, etc?), and as such does the multiple things not as well. Fortunately, it''s shortcomings are not readily apparent.

Transferred to the GUI paradigm, the Unix Philosphy is embodied by plugins, which allow each component to focus on one task and share data. Design is therefore important: each plugin must act as a filter, accepting input and generating output in standard formats. Only a few GUI applications should be standalone, and these should serve as general-purpose plugin bases. Many projects embrace this (KParts, Bonobo), but none of them goes as far out as to make a significant difference in usability.

quote: Could perhaps all this talk about UI also apply to code library interfaces? Could perhaps open source libraries be so hacked to death ("I''m gonna add my function to do this, and I''m gonna call it blahblahmakenosense()!") that learning them is excessivly tough, scaring away potentially good open source programmers?

Well, yes and no. In good Open Source, one person (or a small group of people) have the final say on what gets added. Programmers have a lot of experience with code (duh!) so they have a "feel" for what constitutes good code interfaces. They also have a lot of examples of flawed code interfaces, or code interfaces that haven''t scaled or evolved well (*cough* Win32 *cough*) to show them how not to structure things. In the real of UIs, programmers don''t really know too much. The Open Source motive of "scratching your own itch" just doesn''t cut it when making software for non-programmers and even non-technical people; you can''t ask them to adapt to the way your software works ("If you don''t know how to use it, you shouldn''t be using it"-style elitism).

What Open Source, and all computing in general, needs is either hybrid programmers - programmers with a finger on the pulse of "regular user" needs and behavior, or programmers with formal training in usability-related areas like psychology, architecture and ergonomics - or development-minded non-programmers who can provide valuable guidance and feedback on how to structure system and graphical interfaces to best serve the user.

quote: Original post by BradDaBug
Wow! This is the biggest thread I''ve seen in the Unix forum in a while!

Probably because there are often better places to find Unix use and development info than on GameDev. What makes this thread interesting, I think, is that it touches on an issue that all programmers have an opinion about - the IDE. It''s not even necessarily about Unix, because if someone were to write a truly innovative Unix IDE you can be sure it''d be ported to Windows in a snap (unless the individual is a "penguin-loving hippy").

quote: Original post by Oluseyi if someone were to write a truly innovative Unix IDE you can be sure it''d be ported to Windows in a snap (unless the individual is a "penguin-loving hippy").

Penguin-loving hippies usually license their products in such a way that they cannot prevent a Windows port.


God puts an apple tree in the middle of the Garden of Eden and says, do what you like guys, oh, but don''t eat the apple. Surprise surprise, they eat it and he leaps out from behind a bush shouting "Gotcha." It wouldn''t have made any difference if they hadn''t eaten it... because if you''re dealing with somebody who has the sort of mentality which likes leaving hats on the pavement with bricks under them you know perfectly well they won''t give up. They''ll get you in the end. -- Douglas Adams

quote: Original post by Arild Fines Penguin-loving hippies usually license their products in such a way that they cannot prevent a Windows port.

Damn good point!

Oh, and Arild, I read up on SWT. I now recall coming across it recently in a DevX article about how it and/or XML/XUL could put truly cross-platform GUIs within reach, with special implications for Mono and Rotor.

quote: Original post by Oluseyi
No offense, but that's utter nonsense. People want machines that work and do what we want them to do. If you present a system that is affordable, accessible, efficient and reliable, does what users want and need it to do, is easy to learn and use, and doesn't invalidate all of their existing experience and work investment - you have a sure-fire hit on your hands.

(Emphasis mine) Please tell me how a system that's radically different from what the user is used to can be easy to learn and how it gets away without invalidating most (if not all) of their existing experience. Apparently you just misunderstood what I said, because your reply isn't that far from my personal opinion.
I just noticed that I said "from one way to the other". I actually meant to say from one day to the other. Obviously, when a radical change is spread in time over many simpler changes, it is no longer perceived as a radical change.

The point is that many people are afraid of radical change, even when the final system they would change to is objectively better than what they originally had (and for good reasons like retraining and so on).

quote:
As corroboration, I point merely to the fact that Windows Longhorn is going to be a radical departure from existing Windows versions (see Question 2).

Then again, look at this page from the same website. It talks about an idea, Activity Centers, that was to be introduced as a radical change in WinME.
Apparently, some parts of the idea made it into the system, but the rest was delayed until WinXP. Now that WinXP is out, again, much of the change is delayed until Longhorn.
I wouldn't be too surprised if some changes would again be delayed. In fact, the website you linked to also states that Longhorn has been delayed until 2005. If there is indeed another release before Longhorn, chances are that some of the Longhorn ideas will make it into that release to prepare users for the final switch.
In the end, radical changes are first taken back and then integrated piecewise. That doesn't mean the change doesn't occur. But it does reinforce the point that radical change needs to happen slowly, so that it is, in fact, not radical anymore.

Actually, this reminds me of how Linus Torvalds doesn't accept huge "radical" kernel patches but demands that those be broken up into smaller patches that still make sense.

quote:
Makefiles are extremely powerful, just neither intuitive nor user-friendly. There's also the problem that makefiles are designed for command-line tools and CLI invocation, which has made fitting them into IDEs a chore. Add to that the complexity of managing the various entries and logic in make...

Well, if you define "powerful" using the number of things one can do, then you are certainly right. This is proven by the fact that autoconf/automake are essentially used as front-ends to make.
OTOH, physics defines Power as Work/Time, and this definition happens to make much more sense to me. Time obviously depends on user-friendliness, and thus power depends on user-friendliness.
So basically, we end up with the same conclusion, but using different words again.

quote:
Dependency on filename attributes is another flaw of current GUI systems. Macs have file IDs which identify a file's contents as being a particular type. The *nixes need to couple Mac-like IDs with inodes/HFS IDs to give the user really powerful, yet easy-to-use, file manipulation abilities.

Besides, if the system is being integrated with the IDE, doesn't the IDE already define compiler, linker, profiler, etc for use in generating binaries various targets? Why not query the IDE if invoked that way?

Sure, the IDE can provide that information. Some people might prefer to use the CLI, however. (not to mention automated build-tools running as some background process). They should be able to use the same project files for compilation, so a fallback is necessary.

BTW, I definitely agree with you on the file extensions, which is why I mentioned file types. However, as long as file attributes (or Mac-like IDs, or whatever you want to call them) aren't supported and used, file extensions are the best you can get, maybe in combination with a brief scan of the file contents - though that's really just a hack.

cu,
Prefect

[edited by - Prefect on November 22, 2002 11:59:00 AM]