Re: new, little patch and some questions (fw)



sorry, bad reply
-- 
aurelien
--- Begin Message ---
Le jeu 04/12/2003 à 01:54, John (J5) Palmieri a écrit :
[..]
> strcmp is fine though I think there might be a wrapper function
> g_strcmp.  Some of the standard string calls are wrapped and some are
> not.  You can check at gtk.org or a quick glance at DevHelp.  Actualy
> looking at DevHelp shows there is no g_strcmp so strcmp is fine.  In the
> future you can use the refs.  

nice, thx.

> > somme annoying stuff with current scaffold:
> > 
> > * it crashes at close time.
> 
> I noticed this but am busy on other aspects that I figured it would
> either get patched or I would look at it after I merge my features in so
> I could do some bug busting in one swoop.  The main Scaffold devs are
> working on things like GtkSourceView right now which have a broader
> scope but are still part of Scaffold so another hand here would be nice.

it crashes when closing last tab as well, perhaps it's the same problem.
scaffold certainly need improvement to be done on gtksourceviw and
glimmer but you would get more developers with a quite usable release,
the current state with a symbol browser and less crashes would be an
EXCELLENT starting point.

> > * when a compile-error occur, we can click on the error to see the
> > corresponding source-code, nice BUT it doesn't go/show the right line
> > and if the file was previously opened it reopen it.
> 
> Well at least that isn't crashing anymore :-)

sure, it's already fine, perheps it's not so hard to fix (et least for
preventing it to reopen it: if we click again on the link it won't
reopen it a third time so some kind of test is already here)

> > * more complicated to solve: it lacks a symbol browser, is annyone
> > working on it, having some ideas ??
> 
> I'm working on it actualy.  More to the point I am working on a code
> parsing and generation engine that will keep track of every piece of the
> code.  One of the byproducts is a complete symbol browser - that means
> classes, properties, methods, signals along with attributes like public
> and private.  I'm prototyping it in python and then integrating it with
> Scaffold in C.    That is going to take awhile though.

fine, I'd be interrested in this but I don't know anything in python,
would it be possible to have an idea on how advanced it's right now ?
Will it be very C/C++ specific or opened to other languages ?
Have you any timeline for this ?

> > I think I can work a bit on this after I learn a bit more about gnome
> > programming and get more familiar with the code-base
> 
> Great. We would love to have more help.
> 
> > sorry if my english is hard to understand.
> > 
> > PS: please CC me as I'm not subscribed yet
> 
PPS: no need to CC me anymore

> I almost missed your e-mail the first time.  Perhaps putting Scaffold in
> it or gnome-build, gpf, ect...  would draw my eyes.  I've been dropping
> mental packets between all the spam and legit mailing list messages I
> have been getting.


> Oh and feel free to ask questions.
ok, here are a few more:

* there is a "gnome-debug" dir in cvs and a debugger plugin for scaffold
based on it, is someone working on it ?

* I recently worked a bit with eclipse, it's quite slow but has
interresting featuresand seems to have a HIGH level of understanding of
the java syntax:
	- it prevents you when a class, object, method is unknown
	- it prevents you when arguments for a method mismatch
	- it prevents you when you forgot semicolon
...
do you plan this kind of thing in your parser ?
it has as well a TODO list, faster than scanning code for "// TODO"

all this is nice but require a huge interaction with the editor, is
gtksourceview ready for this ?
can we mark a line (with an icon in the margin for exemple) ?

that's all for now, I hope I'm not borrying you with stupid questions,
feel free not to answer :)

-- 
aurelien

--- End Message ---


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]