Re: My vision of gnome-libs (was Re: GNOME 2.0 meeting summary)

[George <jirka 5z com>]

On Fri, Feb 16, 2001 at 02:52:09PM -0500, Havoc Pennington wrote:
> > a) Deprecated things
> > --------------------
> > 
> > Currently, there are a lot of things in gnome-libs stable which have been
> > deprecated in HEAD. And if you have a closer look at gnome-libs stable, you'll
> > find out that some of this stuff was already deprecated and only half-finished
> > in gnome-libs 1.0.x. 
> 
> Unfortunately, some of this such as gnome-stock is not only
> deprecated, it's also sort of randomly rearranged. I personally
> screwed up gnome-stock for example.
> 
> I really think that both deprecating _and_ breaking an API is
> terrible. If people flamed us for that they would be 100% correct. So
> we need to address this issue, perhaps by backing out some of the
> changes to deprecated APIs.

Yes deprecated API should be at the 1.0 level if possible, since an evolving
deprecated API is an oxymoron.  However, it is not a matter of simply putting
in the old files as things will just not work.  For one the old files depend
on gtk1 and imlib.

Speaking of gnome-stock and gnome-dialog, that should be a wrapper or work
well with the GTK+ replacements for gnome2

> Right. Which is why we need to be sure that a) gnome-libs has a clear
> functional definition and b) there are other places to put
> experimental or unfinished things. But so far, a lot of the stuff
> added to gnome-libs HEAD is just as unfinished as the pre-1.0 stuff in
> gnome-libs, and lots of the pre-1.0 stuff still isn't finished.

I tend to disagree here.  Aside from things such as gnome-stock, msot work on
gnome-libs HEAD has been polishing up the working widgets.  That is the ones
that are being used.

> I think cleaning up what's there, making sure it's nice and backward
> compatible, etc. will already be a couple months of work. So that's
> late April. If you freeze then, then you have only 6 months left to do
> the user environment; and you need 2 months at the end of that for
> freeze also; so basically there isn't time to add features to
> gnome-libs while also releasing this year and having a few months to
> do user environment. 

Well, I don't agree completely.  While adding new widgets after now may not
be the best of ideas.  A full freeze would be just as stupid.  Cleaning up
the current stuff in HEAD is likely to result in a few breakages and some API
changes.  So Yes I do advocate not rewriting any widgets, or anything like
that from now on.  So I think a Slush should be more like it.

> Frankly we don't have many people to work on this, either. I'd kind of
> hope that George, you, Iain, etc. would be helping out with
> gnome-core, gnome-utils, help browser, that kind of thing - I think
> that'd be more valuable than spending too much time on gnome-libs.
> Though we do need someone making gnome-libs their primary focus for
> the next couple of months just to get it cleaned up and stabilized,
> even if no new features go in there.

Well, there is a problem with this argument as well.  A LOT of issues in
core/nautilus/whatever HAS been caused by breakage in gnome-libs.  And many
usability issues are related to standard widgets.  I mean you cannot improve
the user interface if you still have the old crappy widgets from gnome-libs.

> Simply removing isn't such a good idea. It should instead get marked
> with macros as we did for GTK, as you mention below. Most apps compile
> nearly unchanged with GTK 2; we did introduce a bit more breakage for
> custom widgets, but pure application code is not very broken. It seems
> to me that libgnomeui currently breaks a lot more application code
> than GTK 2, and this could be a big problem. Miguel warned us about
> this over a year ago, and he was right.

Not really, at least not as far as I see.  1) we do have libcompat 2) we do
have the define for deprecated functions.

> > RFC 1: Please look at gnome-selector.[ch], gnome-file-selector.[ch],
> >        gnome-entry.[ch] and gnome-icon-selector.[ch] and tell me what you
> >        think.
> 
> I have quite a few comments on this I need to send you.
> 
> The general comment I would have though is that I think this is a
> large project. I think it will take several months to finish, and I
> think it should potentially integrate with Nautilus or use some of the
> Nautilus features. I'm basing my time estimate on the fact that
> currently Nautilus is frozen and its hackers are busy, and also the
> time that it took to implement the various widgets and features in GTK
> 2. Also, we've given quite a bit of thought to a new file selector for
> GTK and feel that this would be a substantial amount of work.
> 
> So, my suggestion would be that it's not a good idea to try to rush
> this in to GNOME 2. We could do it as a separate lib, give it time to
> be really nice, and put it in GNOME 2.2, much as GNOME 1.2 added
> gdk-pixbuf. For key user-visible selectors, such as in the panel, if
> you stabilized by say August or September you could still have the
> panel using it for GNOME 2 even. But it's better to have that
> instability in a separate module in the interim, rather than in
> gnome-libs.

I really disagree with this.  We simply cannot have gnome-vfs integration in
apps if we don't have such support in the selector widgets.  This IS a user
interface issue, not just a development issue.

Another thing is that the old selector widgets cause many breakages and a lot
of things don't use them correctly because of their very weird api.  For
example there is no way to properly get change notification on the icon entry
because of a design issue.

Martin's selector widgets have been in the works for over half a year, they
are more ready for prime time then many other things in g-l HEAD.

We provide the old entries in libcompat AFAIK so old apps aren't br0ken.

I don't see any issues with nautilus integration that can't be fixed in the
next say six months.  And no they will not get fixed until Nautilus is being
ported to gnome-libs 2.  Because until then I doubt there will be people with
some ample time.

So I do not think we can afford not to include the selector stuff in
gnome-libs.  And I'd be uncomfortable if the current entry stuff came out in
gnome-libs 2 as non-deprecated api.

George

-- 
George <jirka 5z com>
   Man will occasionally stumble over the truth, 
   but most times he will pick himself up and carry on.
                       -- Winston Churchill

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers