Some of this, some of that, Idea's really.

["Leareth ." <tleareth hotmail com>]

Well, I've been meaning to do this for quite some time, since Gnome
was conceived actually. Ahh well, I tend to get distracted.

I'd like to apologize for any hurt feelings, and or
misunderstandings before hand. I have a way of writing that makes
what I'm writing sound more like an order, then the suggestion it is.
I will end up stating some things in here as fact, when in all
reality, I am just stating my beliefs. But please go on, I would not
be writing if not for the real fact that I believe I may be bringing
new light to some, perhaps new issues. I hope this helps someone out
there, as this is a complete rewrite, damn netscape crashed just
before I was about to press send in hotmail.

Ok, well first off I'll start with the file manager, as IMHO it's not
only a central point of a desktop, it's THE center point.

	A: Simple interface, low on area, high on functionality. Example,
OS/2 & dfm. Simply windows filled with icons, and hotmenu's
(right-click-hold) attached to all icons & top_back(The background
window).

	B: Complex(relative) association structure. Based on a 
directory tree, where you have a "file-types" directory, and 
subdirectorys per filetype. Within each filetype, a link for every app 
capable of handling  sed filetype, and several default handles, 
(default, edit, & print" which are double linked. The hotmenu for a 
filetype will have the 3 defaults on it's primary menu, and all the 
additional enabled app in a "Open With ->" submenu, including the 
defaults, but with there real names, not there double linked names. 
This "file-types" structure is also the ideal place to hold all other 
such filetype default, such as default icons & such.

	C: File individuality. Each file is it's own boss, if you 
decide that out of all other .tex files, you want once single one to 
have it's own icon & wish to associate it with another editor by 
default, you not only can, it should be easily configurable via a 
options menu tied to each file.

	D: Neatness. No leavening lots of "." files lying around in
directory's, just keep it in a database, thats why they exist.

	E: Memory, mobility & brains. Each file should not only be 
mobile between other directory, but mobile within it's own window as 
well. And when you move it within it's own window, it stays where you 
put it, and remembers that place as well, even if you close the 
window. And when you go putting files in other places, it does not ask 
you every time what it's design should be, it has a default set of
(configurable) decisions. and is it makes a mistake, you have a undo
last option, and if it's a long operation, you'll have a cancel
button to instantly revere your decision. And thats not to say that
the default will always be right, so if you drag with the right mouse
button, it goes back to letting you decide. It has brains, and the
ultimate proof of that being, it knows when to shutup & take orders :)

	F: Open new windows by default. Though I do feel that this 
option should be configurable, I also feel that it should fallow the 
by large default of opening a new window on directory open, as opposed 
to changing to sed directory within the originating window.

	G: Name change by by left_singleclick_hold(1)sec on name.

	H: Instant highlightwhen rubberbanding files, not highlight 
after release.

Next, the all important Panel. Weeee!!!

	A: First off, the Panel it self should have it's own
directory, for storage of config files, droped files on panel, auto
applet init, and startup folder.

	B: As to the file drop thing, yes, the panel should in fact be
able to except actual files, not just fake links. This is for several
reasons, first off, no more (cut|copy & paste dest) ala w95, and also
no more copy to desktop and hunt through billions of windows to get
back to the right place on your desktop. As the Panel has a tendency
to float above or to the side of other windows, it is less vulnerable
to such problems.

	C: Applets. The Panel should, of course, be able to swallow
normal X apps, but should also have an extended interface for applet
programming. Applets would come in 2 flavors & be executed one of 3
ways. First kind of applet is a standalone applet, which either the
panel itself runs at startup(all the applets in the applet subdir) or
that get run by the user, and connect to the panel by corba(Which
then, from the executers point of view, exits. Though the applet
remains running) or by applications that wish to add an additional
primary interface. The apps that uses this connection use the same
methods as the standalones, but are useful for applications that
want to remain running & usable after all there windows have been
destroyed.

	D: The Panel should be able to be attached to any side of the
screen or float at the users option.

	E: Directory's placed (True link or actual placement) on the 
panel auto gain an extension arrow & map out as menus when clicked.

	F: The default menu should be actual directories with real sym
links contained within, ".<appname> files only created when they
become necessary.

	G: All options configure able from menus. You wish to have
ASclock running on your Panel, drag it were you want it, select
link(though copy would work, why waste space on your system?) and
goto the options menu & ask for "swallow on" instead of "Normal
view".

	H: The Panel should have a nice clock/cal running, not just 
text date/time. Like ASclock, hell even ASclock it self. I don't mind
ripping things off.

	I: A mount applet should be included with the panel, as should
several other applets, but mount should usable by non root personal,
though you would need a settings area, so that root could give
managed access if desired. But the point being, it would NEED to be
secure, so it couldn't be taken advantage of. For one thing, it
should only run on a local display.

	J: Ok, Sense the Panel also has control of the taskmanager, 
heres that. I believe we should go with something akin to kde's, but 
with submenu's according to creator, eg not all netscapes are on the 
root list, only the ones with different pid's are. Windows with the 
same pid's are listed under a submenu. Other then that, the kde
taskmanager was just about perfect. For me any way.

Ok, I think that covers the panel, now onto bigger & better things
:)
	
	Ok, with themes, comes the need for a comprehensive theme
manager & some default themes. I'm thinking (Next, Mac, SGI, CDE,
Gnome(Yes, we need our own), Gtk-std, & w95 if we really have to...)

	A note on Corba. LEAVE IT ALONE. It is a nice luxury on this
venture, but it is also BIG bulky, and in general, a huge hog. Use it
for small distributed api's & simple message passing. And use
something else if you can get away with it for message passing even.
Remember, SIMPLE!!! Simple solutions are almost always better
solutions. Nothing as mind bogglingly complex as Corba can possibly
be a good thing, but if it's to be used, it should only be when
truly necessary.

	Another note on Corba, we really should devote some time to
"Helping" Mico authors along, they really need 100% Corba 2.2 & I
heard that there namespace was still rather beta. Also, they seem to
have over looked C, and gone strait to C++. This is a mistake that
will HAVE to be rectified. We need not only idl->C++ mappings, but
		
		idl->python
		idl->C
		idl->ObjC
		idl->Perl
		idl->Guile
		idl->Tcl

and a chance of others. Then, once we have the above, there needs to
be an effort made to create our own small, intuitive, object passing
system built on Corba 2.2, but SIMPLE. No exesesive calls, weird
mappings, just a shared lib for each lang, and come objects to use as
building blocks, and a few(FEW) functions for working with them.
Would end up creating corba 2.2 compliant objects & working with
others, but in a very simple fashion. This would give us the power of
corba(if/when) we need it, but also give us a simple interface to it
for most day to day operations that require distributed objects.

	K, now that I've ranted about Corba, lets talk about actual
programming. Now here's something I've done on my own to apps other
people have made, so it is possible, and pretty easy. Take your
program, and give it an over haul. start looking at your program from
the point of view of, gee? if I was going to create multiple
interfaces, what would I NEED to remake per interface. Then go back
and change all of thoughs references to malloc calls. A change as many
of the others as possible to static data. Then compile it as a shared
library, and make a new main, that just loads files under the right
right user, and calls on  the shared lib to do all the work related
to the actual program. It's just like calling "New window" in a gui
app, but it's system wide for all users. NOW DON'T GO GETTING ANY
IDEAS!:), I want to sell this one, I'm broke. I'm the I can't buy
pizza broke. But I also want Gnome to be godlike, so go for it.

BTW: It adds about 5-20% ext mem for a single instance, but following
instances make up for it almost instantly.

On the whole making entire prog's out of scripting languages, I
realize it's an option, but why would you want to? Trying to shoot
yourself in the foot? Trust me, it's an easy target, and this is a
good way...

Oh, and were you REALLY serious about guile??? I really can't stand
lisp & it's relatives. I almost wept when the FSF said thats the way
they were going. Then there like "Oh, but it can emulate other
languages!" Course, then you get "A program, running in a scripting
language thats running in another scripting language." And well, lets
just say I wasn't thrilled with the idea. Only good that that came out
of lisp was emacs. And even then I wouldn't be caught dead programming
for it, but it is a sweet editor, if you wish to call it an editor :)

But really, doesn't Perl sound better? As far as scripting goes,
NOTHING beats Perl :)

Though Tcl IS easier to embed, just less fun to program in...

Ahh... 6:38am. what a night. Well, hope this gets through, and I hope
to here the responses.



Jasper <tleareth@hotmail.com>
-- You've got to lose, to know how to win.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com