Anders Carlsson

Good stuff Anders... Just a question: would these libs stay in until gnome 3.0 so they won't break compatibility with the apps out there? Problem is, that if we pull these ourselves in order to satisfy deps for some apps, there is a good chance that these libs won't even compile with a later gnome version.

Also, if you could add some code optimizations in there (speed, loading times), would be super! :)

thx,
Eugenia

Yay! Having a reorganization in the libraries could be very cool. I know some programs (better said, some packages in packaging systems) that have "important" functionality disabled because it requires on some library that is very high in the dependency chain (thus pulling in a lot of other stuff). And there are other programs that reinvent the wheel just to avoid a few extra GNOME libraries, when they'd better use them if the dependencies were flatter. Good to know someone is looking at this; thanks!

Eugenia: API/ABI won't be broken before GNOME 3.0 so the libraries will stay (I guess with a LIBGNOME*_DISABLE_DEPRACATED #define so that it's possible to make sure that your applications build without using deprecated functions.

You said that you are making the dependency chain that is more flat, how about instead having no dependencies at all?! I love Linux and all, but dependencies have to go somewhere and stay there.

Gnome is great but I don't see why it has to be broken into so many packages. Just make it one, I say. Upgrading your Gnome installation is a rite of passage, and is one of the things (including dependencies) that is keeping Linux from mainstream success.

Mr. LaCroix, please let me show you why I believe you are wrong.

The dependency chain should be as flat as possible, but it's inexistence would break the unix spirit. That's because you would need the application to have it all built in.

I believe that mantaining the unix philosophy of design is more important for Linux than 'mainstream success'; and I also don't see that as an impediment to it's success -- I believe it to be it's greatest strenght.

RE: Jeremy LaCroix - upgrading gnome gnitemare:

When I upgrade gnome on my Debian system it is very simple. I know this is not a "true" solution to the problem, but I you don't like upgrading, perhaps you should switch to something that makes it eaiser.

Jeremy: Your distribution will handle the upgrade issues for you. That is all you have to do is to press "upgrade" and it will successfully install the dependencies. If you are using a distribution that doesn't package GNOME for you, you are not using a mainstream linux distribution anyway...

Having the GNOME libraries splitted up in different modules makes a lot of sense maintenance-wise and not something that is user visible (provided the user use a non-geek-toy distribution).

Gnome2 programs start much slower than Gnome1. Look at gedit2, which is supposed to be light-weight editor but starts much slower than the editor beast Emacs!

Gnome libs need some profiling to identify where the cpu spends most of its time.

Start the profile engine!

While having a single, gargantuan GNOME package sure is unpractical, not in the UNIX tradition, etc., IMHO Anders' work is a step in the right direction: a GNOME release consisting of no more than 10-12 packages, i.e. gnome-libs, *-desktop, *-net-apps, *-office, *-office-libs and the like.

This would considerably reduce dependancy hell, and help in keeping things clean and well ordered.

My 0.2 �, of course.

rehdon

I use / program Gnome apps almost from its beginning.

quite frankly , i've never understood why we should reinvent API at every major release and should not do the simplest,easiest and more productive thing :

GET THE BEST IDEAS FROM OTHER APIs!!!

I think this is a problem that not only graphical apps ( but UNIX apps in general) have.
Reinvent the wheel.

People , let's take a good look at Bill's s*** and MacOSX API and all other good APIs out there.
Implement their best capabilities in a very SIMILAR way , so we can keep a good compatibility with them in the future.

The desktop on UNIX systems with be far more advanced now if this would had been done.

I saw on a mailing list that owen taylor (or some big GNOME developer) said that we SHOULD CHANGE API at GNOME 3.0

MAN , your task should be the FREEZING of the API , not creating incompatibilities at every major version .
I had many problems porting my software fropm gtk1 to gtk2. Please dont make me do this again.

And one more thing: implement the god damn MDI windows in gtk.(sub-windows like qt)
Every f***** decent API got them.

I use / program Gnome apps almost from its beginning.

quite frankly , i've never understood why we should reinvent API at every major release and should not do the simplest,easiest and more productive thing :

GET THE BEST IDEAS FROM OTHER APIs!!!

I think this is a problem that not only graphical apps ( but UNIX apps in general) have.
Reinvent the wheel.

People , let's take a good look at Bill's s*** and MacOSX API and all other good APIs out there.
Implement their best capabilities in a very SIMILAR way , so we can keep a good compatibility with them in the future.

The desktop on UNIX systems with be far more advanced now if this would had been done.

I saw on a mailing list that owen taylor (or some big GNOME developer) said that we SHOULD CHANGE API at GNOME 3.0

MAN , your task should be the FREEZING of the API , not creating incompatibilities at every major version .
I had many problems porting my software fropm gtk1 to gtk2. Please dont make me do this again.

And one more thing: implement the god damn MDI windows in gtk.(sub-windows like qt)
Every f***** decent API got them.

@victor mierla: 1. breaking API on major versions is quite understandable - like the ABI compatibility during minor/subversion releases. And please remember that you might install various versions of a library in parallel. Oh, and QT breaks on each major version too. 2. MDI is a "no-no". It's been years since each MDI application (except Photoshop, due to the UI-feticism of its users, and Office, where it's "masked") is switching to the document-window paradigm. MDI is pure non-sense, from a UI point of view: the window handling should be done by the window manager, not by a program. Period. Wisely enough, GNOME-people ripped it off from libgnomeui long ago.

Zefram :: Aplications like Photoshop or gimp are showing the exact reason why MDI in a must-have.

Aplications who open many windows may need to deal with the windows in a special way (they arrange thw sub-windows optimal in a parent-window). This cannot be achieved by a window mager dealing only with toplevel windows (like gtk/metacity) because however good the arranging window algorithm is in WM it cannot deal with all the situations that can appear.

That's why working with Photoshop is a pleasure and working with gimp a nightmare .

I was a webdesigner for some time and trust me i know what i'm saying.

I will tell you this:
- gimp - opened 7-8 windows minimal
- terminal - (before multi-terminal windows) - opened 3-4 windows min
- browsers - idem (before multi-term like opera)
opened 3-4 windows

So i have some 13 toplevel windows opened at the same time. Of course that are workspaces but this does not solve problems , but even makes it difficult to remember in what workspace were the windows.
Imagine how can metacity or other WM deals with 13 windows. when i switch to anopther app for ex browser would be hard to return to one of the 7-8 windows opened by gimp.

The solution that gtk developers are aproaching ( see gnome-terminal or mozzila multi-window model does not work for app like gimp were you need to show many child windows at the same time).

And one more thing:

I do not understand why developers are trying to impose their vision upon the users.
If i(and many others) want to use MDI-WINDOWS i think they should implement it also in gtk ,beside their desired model.

SOme say that using pointers is bad programming because their use is the root of 90% of programming mistakes but nobody takes them out of C(c++) compiler.

Indeed they were removed in languages like Java/VB but their behaviour can still be emulated.

I don't know iif this is the best analogy but please....

GIVE ME THE MDI (sub-windows) ...even as a separate lib... ;-)

Bye

Zefram :: Aplications like Photoshop or gimp are showing the exact reason why MDI is a must-have.

Aplications who open many windows may need to deal with the windows in a special way (they arrange thw sub-windows optimal in a parent-window). This cannot be achieved by a window mager dealing only with toplevel windows (like gtk/metacity) because however good the arranging window algorithm is in WM it cannot deal with all the situations that can appear.

That's why working with Photoshop is a pleasure and working with gimp a nightmare .

I was a webdesigner for some time and trust me i know what i'm saying.

I will tell you this:
- gimp - opened 7-8 windows minimal
- terminal - (before multi-terminal windows) - opened 3-4 windows min
- browsers - idem (before multi-term like opera)
opened 3-4 windows

So i have some 13 toplevel windows opened at the same time. Of course that are workspaces but this does not solve problems , but even makes it difficult to remember in what workspace were the windows.
Imagine how can metacity or other WM deals with 13 windows. when i switch to anopther app for ex browser would be hard to return to one of the 7-8 windows opened by gimp.

The solution that gtk developers are aproaching ( see gnome-terminal or mozzila multi-window model does not work for app like gimp were you need to show many child windows at the same time).

And one more thing:

I do not understand why developers are trying to impose their vision upon the users.
If i(and many others) want to use MDI-WINDOWS i think they should implement it also in gtk ,beside their desired model.

SOme say that using pointers is bad programming because their use is the root of 90% of programming mistakes but nobody takes them out of C(c++) compiler.

Indeed they were removed in languages like Java/VB but their behaviour can still be emulated.

I don't know iif this is the best analogy but please....

GIVE ME THE MDI (sub-windows) ...even as a separate lib... ;-)

Bye

Victor:

"I was a webdesigner for some time and trust me i know what i'm saying."

I am a web designer as well ... how does that make you an expert on this? it's irrelavant ... i'm also a programmer ... and database designer ... and admin ... no offense, but who cares?

funny you should mention photoshop ... you ever tried it in the most common environment for graphics design: MacOS? no MDI ... very similar to the gimp (or rather vice versa) ... it's very handy and easy to work with and you're never confined to a window that does nothing but contains other windows ... it just doesn't make sense ... i've been using MySQL Command Center in MDI mode and SDI mode ... MDI is a pain ... like having (to draw a parallel to web design) a scrollable element within another scrollable element ... when the inside element is partially obscured so that the outer element has scrollbars, it's horrible to work with ... should the scroll wheel control outside? inside? what about a text area ... it's a pain to edit text when you have to scroll both the main browser window AND the textarea box just to see all of the text ...

if the designers want to implement SDI, there's nothing stopping you from not using the app ... besides, do you want the overhead of having the program have to know how to do both modes?

i do, however, wish it could operate more like MacOS ... eg: i open up photoshop and have a few things like the toolbox, layers, etc open in addition to an image ... then, i click on the desktop to find another file i want to copy something from in photoshop and all of photoshop's windows (except the main image) disappear until i re-click on the image window ...

Victor:

Also, please be careful you don't hit reload or do anything weird, because your posts are all doubled ... kinda funny that a web designer that "knows what they're saying" is the only one having issues with this :P

Slimming down the massive dependency list and getting rid of the API cruft are the first good things I;ve heard about GNOME in a long time.

Having said that, maybe we should have a look at GNUstep, the forgotten child of de *NIX desktop world. It's pretty much feature complete and consists of just 3 major packages to be pulled/compiled from CVS. It compiles _real_ quick and offers a sublime API ie. the Openstep/Cocoa thing, programmable in a sane OOP language: Objective C.

In fact, maybe we should ditch the whole GNOME thing and start coding apps for GNUstep instead.

Reinventing the application framework wheel is just _so_ 90's ;)

In my humble opinion, given as an experienced terminal and GUI user since '91, MDI is a very restrictive and counter-intuitive way of organizing information. I prefer having many toplevel windows over one toplevel window divided into chunks of plaques vieing for domination. (And those blasted scrollbars that appear whenever you move a window a bit out of the main application, bwah!)
Of course this is a matter of subjective preference, but once I got used to using multiple desktops and no tasklist whatsoever (so no windows get minimized on my desktops) I began to understand the overall philosophy of 'usability'. What might actually solve the case of managing 10+ toplevel windows all belonging to one applications are the windowmanager hints. Hint the WM that these windows belong to GIMP and behave in this-and-that manner. Problem solved?

glandix :::

Victor:

"I was a webdesigner for some time and trust me i know what i'm saying."

glandix::
I am a web designer as well ... how does that make you an expert on this? it's irrelavant ...

It's relevant from the point of view of working with many windows opened at the same timne (web browsers , terms, gimp,etc).

Usually a normal X session does not involve so many opened windows at the same time. That is the relevancy i'm talking about , not other one.

glandix::
"ever tried it in the most common environment for graphics design: MacOS? "

Sorry , i wish i could tell i did ;-)

"..like having (to draw a parallel to web design) a scrollable element within another scrollable element ... "

No problem for me....

"element ... when the inside element is partially obscured so that the outer element has scrollbars, it's horrible to work with ... should the scroll wheel control outside? inside? "

2 aproaches :
win aproach : click on subwin the scroll..
gtk aproach : mouse focus controls scrolling...

Personally , i prefer gtk aproach

"it's a pain to edit text when you have to scroll both the main browser window AND the textarea box just to see all of the text ..."

Yep , this is a problem....found it in IE...
But i would not call it 'pain'.

Sorry for the double posting....must be this old IE... ;-)

I'd just hate to see MDI in the gnome libraries, not only is it clumsy imho, but totally counter productive when using many monitors (no, I don't want to maximise one application/window over both, because then it covers other windows I might need/use). And this doesn't even start to cover issues with own keybord shortcuts for maximizing in one direction or other, or mouse focus settings.

heh.. I'm a webdeveloper too..